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

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

This is a sound proposal but I think it may inadvertently drop one aspect that I thought Robert kept open as a possibility, which is that there could be other identification information that higher level protocols might want to use. In this context I think we should leave open including a possible string form that also included a delegated signer relationship that incorporated ordinary business practice in appropriate contexts such as

John Doe, Vice President, for Acme Corporation. 

This could in some contexts borrow from certain X-509 information, such as Organization and Organization Unit, but should be broad enough to work with the other types as well.

I think both the proposals are on the right track.

---------- Original Message ----------------------------------
From: "Nick Pope" <pope@secstan.com>
Date:  Sun, 4 May 2003 22:01:23 +0100

>Robert, Trevor and all
>
>I broadly agree with what you propose.  May I suggest some simplifications.
>
>Since the SAML NameIdentifier without any of the optional attributes is a
>string the first requirement for a Simple Name string can be met by the SAML
>NameIdentifier structure.
>
>I am not cear what is being proposed by RFC 3280 GeneralName.  I assume that
>this doesn't mean the ASN.1 encoded structure but the ability to include all
>the name forms in GeneralName.  Many of these are already included as name
>type in SAML NameIdentifier including X509SubjectName, emailAddress.
>
>Thus I propose that text is updated as follows:
>
>"..... This will include:
>1) The name of the requestor as a simple name string or specific name forms
>such as X509 subject names, email addresses, IP Address, email address, DNS
>Name, EDI party name, URI, directory name.
>
>Note: The SAML NameIdentifier syntax can be used to encode this information.
>
>2) Information provided to confirm the name of the requestor such as a SAML
>Assertion, WSS Token, Kerberos Token ...."
>
>In addition, I propose that the DSS service may identify the means used to
>confirm the name rather than carrying the token used to authenticate the
>user.
>
>Nick
>
>> -----Original Message-----
>> From: Robert Zuccherato [mailto:robert.zuccherato@entrust.com]
>> Sent: 02 May 2003 19:58
>> To: 'Trevor Perrin'; dss@lists.oasis-open.org
>> Subject: [dss] Requester Identity (was RE: [dss] requirements draft 4)
>>
>>
>.....
>
>> 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.
>>
>
>
>