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] Representing requestor's identity


At 12:14 PM 5/20/2003 -0400, jmessing wrote:


>I would think that the attributes contained in the contribution from you 
>and Nick should be added as a possible source for other information 
>supporting the name. The three mentioned in that paragraph should not be 
>exclusive. Any method should be supported, even ones that we do not know 
>about today, if we are simply describing methods of authentication or 
>supplemental information about it.

The intention of the 2nd bullet was that "Information supporting the name" 
within the Requestor Identity element could be anything.  I.e., that part 
of the Requestor Identity would be defined totally generically in the 
"Protocol and Core Elements" doc.

However, the "Protocol and Core Elements" doc might also define a few 
initial things that can be used as "Information supporting the name", to 
get the ball rolling, and the 3 things listed would be good candidates.

However, these would not be restrictive: other documents could extend the 
Requestor Identity element to contain other things.  It would be left to 
profiles to decide which of these they want to allow.


>Also, in the first part, where is a WSS security token and string name? 
>Are we back to SAML again? I thought we had resolved that issue.

I think if you really want to put in a WSS security token, that would be a 
better fit in the 2nd part.  The first part should just contain a name, 
using some sort of simple type/value format:

<Name Type="#emailAddress">Alice@Acme.Com</Name>

Trevor



>---------- Original Message ----------------------------------
>From: Juan Carlos Cruellas <cruellas@ac.upc.es>
>Date:  Tue, 20 May 2003 16:26:25 +0200
>
> >Dear all,
> >
> >One of the issues that we should try to deal with during these days is the
> >issue of representing requestor's identity and how this should be included
> >in the requirements document.
> >So far the latest version of teh requireements document says in its 3.2.1
> >section:
> >
> >"If the server is not signing with a key specific to the requestor, then
> >the server might want to
> >represent the requestor's name, and possibly details of how the requestor
> >authenticated, in a 205
> >signed attribute. We will define an XML element for this purpose, which
> >will contain: 206
> >• Requestor Name (in a type/value format such as a SAML NameIdentifier) 207
> >• (Optionally) Information supporting the name (such as a SAML Assertion,
> >Liberty Alliance 208
> >Authentication Context, or X.509 Certificate)"
> >
> >Does this constitute a basis for reaching a consensus or is there anyone
> >thinking that
> >something should be changed or added?
> >
> >
> >Juan Carlos.
> >
> >
> >
> >You may leave a Technical Committee at any time by visiting 
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
> >
> >
>
>
>You may leave a Technical Committee at any time by visiting 
>http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php



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