[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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-SOAPMessageSecuri 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]