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

[Robert Zuccherato <robert.zuccherato@entrust.com>]

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.  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.

Is this acceptable?

	Robert Zuccherato

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net] 
> Sent: Wednesday, April 30, 2003 8:14 PM
> To: dss@lists.oasis-open.org
> Subject: [dss] requirements draft 4
> 
> 
> 
> 
> I updated the draft, mostly just to tighten the language, 
> clean up typos, 
> and mention a couple things like:
>   - extensibility to linking timestamps
>   - the client sending dsig:References for URIs that 
> contribute to the 
> transform chain
> 
> However I also changed "3.2.1 Requestor Identity" drastically:
> 
> "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.  We will not specify how this is done, leaving it to 
> higher-level standards that build on DSS.  Options include an 
> RFC 3280 
> GeneralName in CMS, and a SAML Assertion in XML-DSIG."
> 
> This reflects my growing feeling that we shouldn't concern 
> ourselves with 
> the contents and semantics of signatures, but should just 
> focus on the 
> technical issues of sending to-be-signed or was-signed data 
> and retrieving 
> back a signature or verification result.  Doing otherwise 
> seems like a can 
> of worms.
> 
> But this is just to spur discussion, if people disagree we'll 
> change it 
> back..
> 
> Revision tracking is enabled in the word doc:
> http://trevp.net/dss/dss_requirements_draft_4.doc
> http://trevp.net/dss/dss_requirements_draft_4.pdf
> 
> Trevor
>