RE: [dss] Representing requestor's identity

[Anthony Nadalin <drsecure@us.ibm.com>]

>I disagree here - I think we should *only* support SAML as far as
>representing the authentication event goes, since it's the only well-known

>technology for doing this (that I'm aware of).  WSS UsernameTokens aren't
>intended for this purpose - they don't provide for expressing usernames in

>different "name forms", and they don't provide for saying anything about
>who authenticated the subject, the authentication method, or the
>authentication time.

Disagree, there are lots of technologies that represent an authentication
event, Kerberos
is one of them. Need a extensible mechanism, what you propose is not, so we
need a way
expressing name forms including:

- Simple name string
- RFC 3280/X.509 general name (possibly encoded as an LDAP string)
- SAML Assertion
- WSS UsernameToken
- Kerberos
- Other name forms to be identified at a later date

Also who ever told you that UsernameTokens aren't intended for this purpose
is wrong, these
can and are used as name assertions.

Anthony Nadalin | work 512.436.9568 | cell 512.289.4122


|---------+---------------------------->
|         |           Trevor Perrin    |
|         |           <trevp@trevp.net>|
|         |                            |
|         |           04/28/2003 01:36 |
|         |           PM               |
|---------+---------------------------->
  >----------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                              |
  |       To:       Nick Pope <pope@secstan.com>, dss@lists.oasis-open.org                                                                       |
  |       cc:                                                                                                                                    |
  |       Subject:  RE: [dss] Representing requestor's identity                                                                                  |
  >----------------------------------------------------------------------------------------------------------------------------------------------|




At 06:51 PM 4/28/2003 +0100, Nick Pope wrote:

>Trevor,
>
>What exactly do you mean by ASN.1 syntax?  Do you mean take the basic
ASN.1
>structure and redefine it in XML?

CMS is already in ASN.1, so if we use RFC 3280 GeneralName as the "name
syntax" for identifying the requestor within CMS signatures, we wouldn't
have to redefine it in XML or base64-encode it or anything.

[...]
>A more generic approach could be a "name form"
>identifier followed by the Name value encoded as a string.

That's basically what a SAML <NameIdentifier> is.  We could borrow that or
define our own, either way would be so easy I don't think we need to sweat
the details now, if we're in agreement that both XML and CMS should have
some simple "name syntax" (as simple as just a type identifier followed by
a string or structure).


> > Then for both XML-DSIG and CMS, we should allow the use of a SAML
> > Assertion
> > in place of the name syntax when information about the
> > authentication is to
> > be represented.
> >
>As well as SAML we still need to cover WSS UsernameToken and allow other
>externally defined structures for representing authenticated identities.

I disagree here - I think we should *only* support SAML as far as
representing the authentication event goes, since it's the only well-known
technology for doing this (that I'm aware of).  WSS UsernameTokens aren't
intended for this purpose - they don't provide for expressing usernames in
different "name forms", and they don't provide for saying anything about
who authenticated the subject, the authentication method, or the
authentication time.

Trevor