RE: [dss] Profile Identifiers

[Paul Madsen <p.madsen@entrust.com>]

The possibility of a client being required to insert a profile identifier
raises a question on how abstract profiles (e.g. policy-wise server) work
with concrete profiles. 

Imagine a SOAP Gateway which will, upon interception of an outgoing SOAP
message, request a signature of a DSS Server for inclusion in the WSS Header
block. There are two flavours of the Web Services Security DSS profile, one
relevant for policy wise clients (a gateway to which signing policy has been
provisioned) and another for policy wise servers.

How does the client differentiate between these different flavours for the
WSS profile - are there two different identifiers along the lines of
(anticipating profile identifer as an attribute)

<SignRequest profileRef="dss:profiles:wss:pws"/> and <SignRequest
profileRef="dss:profiles:wss:pwc"/>

the implication being that the WSS profile would itself define the two
flavours 

or should a client indicate both a concrete profile and an abstract profile
with two separate identifiers

<SignRequest abstractProfileRef="dss:profiles:abstract:pws"
concreteProfileRef="dss:profiles:wss"/>

where the client would be asserting to the server that its expectations were
that both the abstract and concrete profiles were 'active'. The implication
is that the abstract profile is defined completely separately from any
concrete profiles.

Paul

>-----Original Message-----
>From: Nick Pope [mailto:pope@secstan.com]
>Sent: Friday, February 13, 2004 6:57 AM
>To: Trevor Perrin; dss@lists.oasis-open.org
>Subject: RE: [dss] Profile Identifiers
>
>
>Trevor,
>
>I generally agree.  Each implementable concrete profile should 
>have a URI.
>
>However, in the case where there are two concrete profiles 
>specified in a
>document as described below.  An implementation need only 
>implement one.
>So, for example, I could implement the 
><dss:TimeStamp/XMLTimeStampToken>
>profile without implementing <dss:Timestamp>.
>
>I like the idea of making this profile identifier part of the 
>main structure
>rather than an optional input.  In fact, I would prefer to make it a
>mandatory element of the protocol which is always included by 
>the client so
>that implementations can easily ensure that it is handling the 
>expected type
>of request from a client and so make implementations more robust.  Can
>anyone think of a scenario when a profile would not be identified?
>
>Thinking about this raised a related question.  Do we need an optional
>version number for a profile so that servers can manage change between
>profile versions.
>
>Nick
>
>> -----Original Message-----
>> From: Trevor Perrin [mailto:trevp@trevp.net]
>> Sent: 12 February 2004 19:52
>> To: dss@lists.oasis-open.org
>> Subject: [dss] Profile Identifiers
>>
>>
>>
>> [I sent this a few days ago, didn't go through... trying again.]
>>
>>
>> Should every profile have a URI identifier?
>>
>> Probably not - profiles too abstract to be implemented don't need
>> one  (Policy-wise, German Signature Law).
>>
>> However, a concrete profile may be further profiled:
>>   - Profile X: Timestamping profile for <dss:Timestamp> objects.
>>   - Profile Y: Timestamping profile for 
><dss:TimeStamp/XMLTimeStampToken>
>> objects.
>>
>> Or,
>>   - Profile X: profile for XAdES
>>   - Profile Y: some more specific profile built on XAdES
>>
>> Y profiles X, but both profiles are concrete, in the sense that
>> they could
>> be implemented.
>>
>> My vote: X and Y both have URI identifiers.  Y's profile 
>document lists
>> both identifiers.  A server implementing Y should be aware that it
>> implements both, and allow requests that reference either URI.
>>
>> --------------
>> Related Question:  Should every DSS request contain the URI
>> identifier of a
>> profile?
>>
>> Right now, <ServiceProfile> is an optional input, which 
>means profiles
>> don't need to support it.  It might be good to make it a
>> mandatory part of
>> all profiles.  It could be an attribute of <SignRequest> and
>> <VerifyRequest>, instead of an optional input.
>>
>> Clients could still choose to send it or not.  This way, 
>clients could
>> always check that they were talking to an appropriate DSS 
>server, if they
>> wanted.
>>
>>
>> Trevor
>>
>>
>> To unsubscribe from this mailing list (and be removed from the
>> roster of the OASIS TC), go to
>> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor
>> kgroup.php.
>>
>>
>>
>
>
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_
workgroup.php.