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

[Trevor Perrin <trevp@trevp.net>]

At 09:54 AM 5/4/2003 -0400, Robert Zuccherato wrote:

>Trevor;
>
> > 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.
>
>True.  But I am thinking that identifying the requester will be a common
>enough requirement that it would be worth our while to include methods for
>doing so in the core protocol.

makes sense.  I still think it would be a little cleaner to separate them, 
but we can decide tomorrow.


> > 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?).
>
>Yes, that is what I was thinking.  The exact list can be modified, but I
>think it would make sense to define an element that can contain a number of
>widely used identifiers.  The higher-level standards can then make use of
>the element as required.

If we do put this in the core protocol, I would prefer an XML Element like

<RequestorIdentity>
   <Name type="emailAddress">Alice@Acme.com</Name>
   <AuthenticationDetails>
       (This element is optional and extensible, could be used for SAML 
Assertion or something else)
   </AuthenticationDetails>
</RequestorIdentity>

I.e., a simple <Name> element that is always present, and an optional 
element that is extensible for giving authentication details, perhaps in 
different formats.

As far as the list of methods you gave:
- Simple name string
- SAML NameIdentifier
- RFC 3280/X.509 general name (possibly encoded as an LDAP string)
- SAML Assertion
- WSS UsernameToken
- Kerberos

I think the <Name> element would take the place of the first 3, the SAML 
Assertion could be used within <AuthenticationDetails>, and it's not clear 
that WSS UsernameTokens or Kerberos tickets belong here (people keep 
advocating their use, but they seem to be talking about:
  - wanting to use them to authenticate, which is fine but a separate subject
  - wanting to use them to indicate the signing key, in which case they 
belong within the signature's dsig:KeyInfo.
  - wanting to pass through the authentication credential (which I can't 
see as a good idea with either of them)
If someone who advocates Kerberos tickets or WSS UsernameTokens could 
explain how they would work in the context of Identifying the Requestor, 
I'll withdraw this objection).

Trevor