RE: [dss] Groups - dss-requirements-1.0-draft-03.pdf - Process a n dDeadline information?

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

Further my earlier message, following some feedback, I need to clarify the
implications of the X.509 general name.

General Name is defined in X.509 RFC 3280 as a choice between a range of
different name forms: including: email address, EDIName, URI, IP Address,
domain name and directory name.  We considering the encoding of we will
probably need to give different XML tags to the differet forms of name, and
considered the appropriate form of encopding appropriate to each type.  LDAP
encoding would only be appropriate to the Directory Name.

Nick

> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: 28 April 2003 14:11
> To: Trevor Perrin; Anthony Nadalin; dss@lists.oasis-open.org
> Subject: RE: [dss] Groups - dss-requirements-1.0-draft-03.pdf - Process
> a n dDeadline information?
>
>
> Trevor, Anthony,
>
> It seems to me that the syntax should be flexible in including a range of
> alternative name forms including:
> - Simple name string
> - RFC 3280/X.509 general name (possibly encoded as an LDAP string)
> - SAML Assertion
> - WSS UsernameToken
> - Other name forms to be identified at a later date
>
> Then for specific usage profiles the particular name form to be
> used can be
> defined.
>
> Nick
>
>
>
> > -----Original Message-----
> > From: Trevor Perrin [mailto:trevp@trevp.net]
> > Sent: 28 April 2003 00:05
> > To: Anthony Nadalin; dss@lists.oasis-open.org
> > Subject: RE: [dss] Groups - dss-requirements-1.0-draft-03.pdf - Process
> > a n dDeadline information?
> >
> >
> > At 04:23 PM 4/26/2003 -0500, Anthony Nadalin wrote:
> >
> > > >> How to Identify Requestor
> > > >> ----------------------------------------------
> > > >> I think 3.2.1 bullets 2 and 3, about what types of signed
> > > >> attributes are
> > > >> used to identify the requestor, should be changed to:
> > > >>   - RFC 3280 GeneralName (for a CMS signature)
> > > >>   - SAML Assertion (for an XML-DSIG signature)
> > >
> > > >It seems to me that SAML assertions work and are easily
> included in our
> > > >spec.  Thus, I think we should certainly support their use.  It's not
> > >clear
> > > >to me that we necessarily need to support any other method
> > until/unless we
> > > >receive a concrete proposal of something else to use or find
> a specific
> > > >deficiency.
> > >
> > >I guess I don't agree, so here is a proposal for a
> UsernameToken, thus we
> > >don't have to have
> > >the baggage of SAML
> > >
> > >  <xsd:complexType name="UsernameTokenType">
> > >             <xsd:annotation>
> > >                   <xsd:documentation>This type represents a
> > username token
> > >per Section 4.1</xsd:documentation>
> > >             </xsd:annotation>
> > >             <xsd:sequence>
> > >                   <xsd:element name="Username"
> > >type="wsse:AttributedString"/>
> > >                   <xsd:any processContents="lax" minOccurs="0"
> > >maxOccurs="unbounded"/>
> > >             </xsd:sequence>
> > >             <xsd:attribute ref="wsu:Id"/>
> > >             <xsd:anyAttribute namespace="##other"
> > processContents="lax"/>
> > >       </xsd:complexType>
> >
> > I agree that, if the DSS service doesn't want to express details
> > on how the
> > requestor authenticated, it might make sense to have a simpler
> way than a
> > SAML Authentication Assertion to express just the requestor's name.
> >
> > I don't think that a WS-Security UsernameToken is a good way of
> > doing this,
> > though.  Looking at the below documents, it seems this element is
> > designed
> > to transport a username, along with possibly a nonce and
> > password.  I don't
> > see any provision for saying what type of name the username is (email
> > address, Distinguished Name, URI, etc.), which is a capability we
> > definitely want.  So why do you think this element is a good way for the
> > DSS to express the requestor's identity?
> > http://www.oasis-open.org/committees/download.php/1046/WSS-Usernam
> e-02-0223.pdf
>
> http://www.oasis-open.org/committees/download.php/1044/WSS-SOAPMes
sageSecuri
ty-11-0303-merged.pdf

I would prefer something like the last suggestion in the below post..  Or
does anyone else have a better idea?
http://lists.oasis-open.org/archives/dss/200304/msg00054.html

Trevor