RE: [dss] some changes in requirements draft 3

[Trevor Perrin <trevp@trevp.net>]

At 06:29 PM 4/9/2003 -0400, jmessing wrote:


>Trevor:
>
>I tend to agree that it is handy to be able to use the entire SAML 
>assertion where the parties agree to use SAML between them. I apologize 
>for not having gotten back to you and the list on my question to Section 
>3.2.1--
>
>[QUESTION:  Is it unduly restrictive to limit permissible methods of 
>representing a Requestor’s Identity to none, a string attribute or SAML 
>Assertion?]
>
>I think your comments tend to support the concern I raised, at least 
>indirectly. In this regard, I am looking at Section 3.3.4, which states:
>
>============================================================
>3.3.4   Authentication
>·       None (or by other means, such as TLS/SSL, IPsec)
>·       Directly to the server within the protocol (perhaps using 
>WS-Security?)
>·       Indirectly via an Authentication Authority (perhaps using SAML?)
>·       Combinations of above
>The protocol should be capable of supporting the above approaches to 
>mutual authentication of the client and server to each other.  Bindings 
>will fill in the details and mandate specific techniques.  Authentication 
>is performed at a lower layer than the DSS protocol itself.  The details 
>of authentication techniques used to access a DSS server are not within 
>the scope of this specification and there is no attempt by this 
>specification to restrict such methods of authentication.
>
>=============================================================
>
>It seems to me that 3.2.1 is much narrower in terms of signature 
>attributes than is 3.3.4. The protocol should allow each of the 
>authentication methods if selected its own signature attributes, rather 
>than simply specifying strings for methods other than SAML.


SAML is a format for describing authentication events, it's not an 
authentication method itself.  A SAML Assertion says something like 
"Alice@Acme.com authenticated using a Password (or Biometrics, or 
Certificate, or Unspecified, or whatever) at Noon on Thursday, as attested 
to by the Acme Corp. Authentication Authority".

So a SAML Assertion could describe any type of authentication.  So I don't 
think the use of a SAML Assertion is limiting.

I think mentioning only a "string" as the other choice wasn't very good 
though.  I would change 3.2.1 to mandate using a signed attribute to 
represent the Requestor's identity, with the attribute being a SAML 
Assertion in XML-DSIG, and a GeneralName (per RFC 3280) for CMS.

Maybe this is too much details to put in the Requirements doc, but we'll 
need to make these decisions sometime, so seems to me it might as well be 
now..

Comments?


Trevor