OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]