RE: [dss] some changes in requirements draft 3

["jmessing" <jmessing@law-on-line.com>]

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. This can also be considered in relationship to the general comment to 3.2 which states :

=============================================================

These requirements [including 3.2.1] don’t apply to the DSS protocol per se, but to the signed and unsigned attributes of the signatures that it produces.

=============================================================

Hence the question whether the text of 3.2.1 is unduly restrictive for non-SAML authentication methods where the parties agree to use such other methods. It seems that a more balanced approach would be preferable. I would not limit the use of SAML, but it would not limit the other methods to none or strings only either, unless they natively only supported these representations of a signer's identity.

Best regards.

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net]
Sent: Wednesday, April 09, 2003 2:02 PM
To: Nick Pope; dss@lists.oasis-open.org
Subject: RE: [dss] some changes in requirements draft 3
At 09:49 AM 4/9/2003 +0100, Nick Pope wrote:

>Trevor,
>
>The reason is that it is a separate assertion, with its implied semantics,
>but part of the DSS information.

If we used a full Assertion then the relying party could process it with a 
SAML toolkit.  Also, in cases where the DSS service was authenticating the 
requestor based on a SAML Assertion, it would be easy just to embed that
Assertion in the signature.

Also, a full Assertion contains some fields that would be useful.
Within the top-level <Assertion>:
  - <Issuer> to identify the Authentication Authority who authenticated the
Requestor (which may not be the DSS service)
  - <AssertionID> to identify the authentication instance for
auditing/dispute resolution
Within an <AuthenticationStatement>:
  - <AuthenticationInstant> to identify when the authentication took place
  - <SubjectConfirmation> specifies data (such as a public key) that the
relying party can use to authenticate the requestor
  - <AuthorityBinding> specifies a service where more information about the
subject can be queried from

So all this could give the relying party visibility into not just who the
requestor is, but how he was authenticated.  So I'd say just use a full
SAML Assertion with an <AuthenticationStatement> (SAML was designed as a
general framework, within which other types of "statements" could be made).


Trevor