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

["Nick Pope" <pope@secstan.com>]

John,

I think that we should think twice before introducing yet another name
structure beyond those already used.  From experience with how naming has
worked in practice with X.509 certificates and Microsoft's active directory,
the application will bend any tools that we provide to their own model of
naming structures.

Nick

> -----Original Message-----
> From: jmessing [mailto:jmessing@law-on-line.com]
> Sent: 05 May 2003 02:01
> To: dss@lists.oasis-open.org
> Subject: RE: [dss] Requester Identity (was RE: [dss] requirements draft
> 4)
>
>
> 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.
> >>
> >
> >
> >
>