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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: [security-services] Action Items 236 and 231


> Wouldn't this apply to the SubjectConfirmation's Recipient 
> attribute as well? 

The assertion profile is independent of the binding used, which I think is a
good thing. Recipient was probably a bad idea in the first place because it
overlaps with the function of the Audience condition and isn't needed now
that the assertion is being signed, but having done it, it's still binding
independent and IMHO there's no language there that makes this ambiguous.

(Contrasted with the old Artifact profile where people did different things
with Response/@Recipient, so I think we'd better leave it alone and not
confuse things further.)

I would have just as soon specified Destination for the Artifact binding for
consistency, but I didn't, and that would be a normative change, rather than
errata.

> Since it's the identity of the peer as determined by the 
> contents of the actual SAML message, how about changing your 
> proposed text from 
> 
> "between the identity in the certificate and the identity of 
> the peer is not defined." 
> 
> to 
> 
> "between the identity in the certificate and the identity of 
> the peer defined by the SAML message content, i.e., SAML 
> message issuer, is not defined."

Fine by me.

-- Scott



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