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

[Anthony Nadalin <drsecure@us.ibm.com>]

Agree, this is the approach that we took with WS-Security, the mechanism
should be extensible and we should define a base of mechanisms, list you
propose seems reasonable.

Anthony Nadalin | work 512.436.9568 | cell 512.289.4122


|---------+---------------------------->
|         |           "Nick Pope"      |
|         |           <pope@secstan.com|
|         |           >                |
|         |                            |
|         |           04/28/2003 08:10 |
|         |           AM               |
|---------+---------------------------->
  >----------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                              |
  |       To:       "Trevor Perrin" <trevp@trevp.net>, Anthony Nadalin/Austin/IBM@IBMUS, <dss@lists.oasis-open.org>                              |
  |       cc:                                                                                                                                    |
  |       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