RE: [wss-comment] Further comments on WSS 1.1 SAML Token Profile

Ron,

Thanks for the clarification. I noticed another nit;

Lines 512-513 contain the following URI; 

http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLID

Which I believe should be

http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID


Cheers

Gudge

> -----Original Message-----
> From: Ron Monzillo [mailto:] 
> Sent: 18 August 2005 15:54
> To: Martin Gudgin
> Cc: 
> Subject: Re: [wss-comment] Further comments on WSS 1.1 SAML 
> Token Profile
> 
> 
> 
> Martin Gudgin wrote:
> > Here are some further comments on WSS 1.1 SAML Token 
> Profile CD doc[1]. 
> > 
> > Gudge
> > 
> > [1]
> > 
> http://www.oasis-open.org/committees/download.php/13405/wss-v1
.1-spec-pr
> > -SAMLTokenProfile-01.pdf
> > 
> > 1.	I don't see what lines 272-281 have to do with WSS. Actually, to
> > be honest, I don't see what sections 3.2.2, 3.2.3, or 3.2.4 
> have to do
> > with WSS. Why are they in this token profile?
> > 
> 
> the token profile describes the WSS use of both sAML v1.1 and SAML v2
> assertions. These sections describe the SAML version differences of
> relevance to (or factor in) their use with WSS.
> 
> > 2.	Lines 378-389 don't seem to support refering to a SAML assertion
> > from an EncryptedData block and Lines 554-556 explicitly rule out
> > referring to SAML assertions from encrypted data blocks why is this?
> 
> lines 386-389 speak to (i.e., rule in) encryption of 
> assertions (as content)
> 
> Lines 554-556 limit the complexity of the profile wrt to the use of
> assertions to convey encryption keys or key encryption keys 
> or assertion
> confirmation keys.
> 
> any of these cases could be enabled if they were deemed important in
> support of some use case. I think we worked backward from the 
> last; that
> is the use of assertions in confirmation keys was seen as unnecessary.
> As such, it was clear that saml assertions would themselves identify
> keys by some other means, and by extension it was felt that
> they would not need to be used to define encryption and key
> encryption keys.
> 
> > 3.	Lines 564-568 seem to disallow refering to an STR in order to
> > sign the STR itself, that is I can ONLY ever sign the 
> referent, not the
> > referee. Is this really the intent? Or is the text trying 
> to say 'if you
> > want to sign the assertion then make sure you use the STR 
> Dereference
> > transform'?
> > 
> 
> no and yes.
> I will clarify this.
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: 
> > For additional commands, e-mail: 
> 
> > 
> 
> -- 
> 	
> 
>