Re: [dss] Requester Identity (was RE: [dss] requirements draft 4)

[Trevor Perrin <trevp@trevp.net>]

At 02:58 PM 5/2/2003 -0400, Robert Zuccherato wrote:

>I guess I'm not too comfortable with not specifying how to represent the
>requester's identity.  It seems to me that this functionality is useful, if
>not required, by a number of our use cases and thus we should at least
>provide the appropriate machinery for the higher-level standards to call
>upon.

We could create some of these higher-level standards ourselves - i.e. do 
both a core protocol and a bindings & profiles doc.  For example, an S/MIME 
signature profile might specify a GeneralName requestor-identity signed 
attribute in CMS.  An XAdES signature profile might specify how to use a 
SAML Assertion within the <SignedProperties> element, and so on.

So I'm not suggesting we should totally shirk these requirements, just 
place them out of scope for the core protocol, and tackle them as separate 
work items.


>I'm also sensitive to the opinion that different applications may
>have different requirements upon the method of identifying requesters and
>thus the mechanism must be left flexible.
>
>Thus I propose the following compromise text for Section 3.2.1:
>
>If the server is not signing with a key specific to the requestor, then the
>server might want to represent the requestor's name, details of how the
>requestor authenticated, or other identifying information in signed
>attributes.  There are a number of methods for identifying the requester and
>various amounts of information that may need to be included regarding
>details of the authentication event and delegation of signing privileges.
>In order to accommodate these requirements, an extensible list of options
>will be included in the definition of the signed attribute.  This list will
>include:
>- Simple name string
>- SAML NameIdentifier
>- RFC 3280/X.509 general name (possibly encoded as an LDAP string)
>- SAML Assertion
>- WSS UsernameToken
>- Kerberos
>It will be left for higher-level standards that build upon DSS to decide
>upon the particular form of identification used in any specific environment
>and the amount of information that must be included.

Are you saying the core protocol should define an XML element that can 
contain any of the above things, and then higher-level standards will 
profile use of this element (by mandating or disallowing certain of its 
choices?).

Or are those all intended to just be examples of things that higher-level 
standards could support?

Trevor