Re: [wss] SAML profile and interop scenario documents notes

[Ron Monzillo <Ronald.Monzillo@Sun.COM>]

Vijay,

Thanks for the comments. Some questions below.

Vijay Gajjala wrote:

>Greetings,
>
>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 
based
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.

Thanks,

Ron

>
>Thanks
>Vijay
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.
>
>  
>