RE: [dss] Profile Integration proposal

[Trevor Perrin <trevp@trevp.net>]

At 12:43 PM 4/7/2004 -0400, Paul Madsen wrote:
>[....]
> >  - Under the "PM" note, it almost sounds like the
> >code-signing profile is
> >being called "implementable", which isn't correct.
>
>That was my interpretation/guess. If its not the case (ie. code-signing is
>not implementable withotu further profiling) then the distinction between
>code-signing and policy-wise is merely that one targets a specific
>application and the other not.

Right, I liked your "vertical" vs. "horizontal" terminology here.


> >  - I don't think all abstract profiles need URIs, but I agree
> >URIs could
> >be useful for abstract profiles (such as for code-signing, in
> >establishing
> >a base URI that the sub-profiles extend).
>
>To my mind, since abstract profiles can only ever be relevant through their
>profiling, they need URIs (for just the reason you state).

The reason I stated was pretty minor: concrete profiles can extend an 
abstract profile's URI, if it helps to organize things, but that's the only 
significance it has.  The intended use for the URI was just for the client 
to label which profile it is operating under, when it contacts the server.

So I don't think abstract profiles "need" URIs, but if they want to define 
them, so their sub-profiles can extend that name-space if they want, that's 
fine.


>For concrete profiles, its not a given that they will be further profiled
>and so wont not need a URI for that reason, but of coure require one for use
>in the

Your sentence was truncated here, at least in my mail client.  If I had to 
complete it, I'd say:

"protocol, which is the chief intended use for URIs."

:-)


>  Agreed, the issue however is how to determine, at the time an abstract
>profile is being defined, whether or not it will subsequently be

Something weird happened to this email - that fragment of text has nothing 
around it...


> >  - A profile might derive from *multiple* super-profiles, in
> >which case
> >you can't expect the URI to extend the super-profile's URI.
> >This could be
> >noted.
>
>Good point, perhaps a concrete example might be if Frderick's WSS profile
>didn't itself account for the policy-wise scenario, then it would be
>relevant to capture the combination.
>
>Somebody else could define a new profile with either of the identifiers
>'pws:wss' or wss:pws'
>
>The alternative would be Andreas's suggestion below to allow the requestor
>to indicate both 'wss' and 'pws' in its request and place the burden of
>interpretation on the DSS server. We would likely need to define an
>corresponding fault message for 'no intersection of profiles'.

I don't like the idea of "auto-merging" profiles.  Different profiles will 
probably conflict, so if you want to combine them, human intelligence will 
be needed to figure out which requirements from each take precedence, and 
produce a new profile documenting this.


> >  - The "Note" at the end isn't clear to me.
> >
>
>Merely that, if the DSS Server could determine the appropriate sub-profile
>by examing which elements are or aren't present in the request, then it
>would be sufficient to merely label the super-profile with a URI. This
>implies alot of work and processign for the server so it would seem best to
>require the DSS client to explcityl call out which sub-profile was in
>effect.

Right now the client is *not* required to call out the profile.  If it 
doesn't, it's at the mercy of the server to use whichever profile it 
wants.  I imagine many servers will only implement a single profile, so the 
client gets no choice.

At least, this is implied by the text in section 3 of the core spec.  I'm 
not sure if it needs to be more explicit.

[...]
> >However, if a particular concrete profile wants to subclass several
> >incompatible horizontal profiles, then it could define some
> >new optional
> >input(s) as selectors to switch between
> >policy-wise/non-policywise, German
> >Sig-Law/Belgian sig-law/French Sig-Law, etc..  I think it
> >needs to be up to
> >the concrete profile to define these selectors, not the core,
> >since the
> >details of what they mean, how many of them are needed, etc.,
> >will vary.
>
>But we don't want different concrete profiles defining unique switching
>mechanisms. The URI should be the flag.

That's where we get the combinatory explosion, if we need a unique URI for 
every combination of options.  For example, if a profile can be used with:
  - policy-wise / non-policy-wise
  - German sig-law / Dutch sig-law / French sig-law / Belgian sig-law
  - Asynch / Non-Asynch

That would be 16 URIs.  So it would be better to internalize these as 
independent optional inputs, somehow.

I dunno.  We may be worrying about something that isn't really a problem 
yet.  I think we should wait for the concrete profiles to develop further, 
and see how the concrete profiles choose to use the abstract profiles, 
before deciding on anything drastic (like sending multiple URIs to the server).


Trevor