OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

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

Subject: RE: [wss] SAML profile and interop scenario documents notes

Looking further into issue #4, the ValueType attribute on STR should be
sufficient for handling multiple profiles. Implementations would define
a new URI for a new profile. 

-----Original Message-----
From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] 
Sent: Tuesday, April 13, 2004 7:49 AM
To: Vijay Gajjala
Cc: wss@lists.oasis-open.org
Subject: Re: [wss] SAML profile and interop scenario documents notes


Thanks for the comments. Some questions below.

Vijay Gajjala wrote:

>Some issues re SAML interop scenarios and profiles docs...
>Issue 1: In the interop scenarios doc, some of the examples used 
>MajorVersion = 1, MinorVersion = 0 in the SAML assertion. Shouldn't 
>this be be MajorVersion = 1, MinorVersion = 1 as this is the latest 
>public SAML spec. The SAMLCore and SAMLBind documents use SAML version 
>of 1.1...
>Issue 2: Some scenarios in the doc do not use Conditions elements, 
>others do. Should we be consistent? It seems like lifetime as expressed

>thro conditions are fundamental to security tokens and as such MUST be 
>required by our profiles and interop scenarios. Thoughts?
By your choice of the word "scenarios", I presume you are referreing to
the interop scenarios document, as apposed to the STP.

That said, I think your question also applies to the STP.

That is, should we require that assertion lifetimes be defined within
the assertions we use with the profile, and should we require recieivers
to reject msgs protected by assertions with conditions (especially time
conditions) that are no  longer valid?

I think the high level answer is yes, but I guess I'd like to understand
how others feel about this.

The content of sender-vouches confirmed assertions may be defined by the
vouching sender, in which case, it would seem inappropriate for the
receiver to depend in any significant way on limits established by the
sender of the assertion.

When the content of a sender-vouches or holder-of-key confirmed
assertion is signed by a third-party assertion authority, it would seem
like the receiver processing model could(and perhaps should) be
sensitive to conditions (includining
lifetime) in the assertion.

>Issue 3: In the interop scenarios doc, for the NameIdentifier element, 
>the format attribute is not used, but the NameQualifier attribute was 
>used. The next revision of SAML core doc seems to move in terms of 
>favoring format attribute. It would be nice for us to do the same.
>Issue 4: If an implementation needs to comply with multiple profiles, 
>how do we indicate which profile of SAML token we are talking about? 
>One option is to use the SAML advice field, though the concern here is 
>that this field is not subject to processing requirements. Thoughts?
Please describe what you mean by needs to comply with muliple profiles.
Also, is the use of ValueType in STR sufficient to identify the profile
in use?
If not, please provide an example that exposes the problem you are
trying to solve.



>To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to

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