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] Use of Audience as delegation flag

> An internal comment from Oracle about the use of an <Audience> element 
> to "flag" an assertion that might be delegated.

That is not precisely my interpretation of this use of Audience.

> In sstc-saml-constrained-delegation-draft-00 an audience 
> element with value:
>     urn:oasis:names:tc:SAML:2.0:profiles:delegation
> is used to signal delegation.

That is the phrasing in the document, but a better way of stating it would
be "an audience element with value ... is used to indicate the enclosing
assertion was issued in accordance with this profile".

In other words, it's a profile that imposes a particular interpretation on
fields that in general have no profile-independent meaning.
SubjectConfirmation, in this case.

> Now, core-02 describes <audience> in the following way:
> <Audience>
> A URI reference that identifies an intended audience. The URI reference 
> MAY identify a document that describes the terms and conditions of
> membership.

This is the general meaning which is being attached.

> The question is whether this is an appropriate use of <Audience>. The 
> introduction of a new element, as is the case for <OneTimeUse> and
> <ProxyRestriction> might be more appropriate.

I think the real alternative is actually to define a new SubjectConfirmation
Method. I'm of the opinion that defining Holder of Key was a mistake because
it's precise meaning isn't captured in the definition. I would have rather
seen specific profiles (like this one) that use key proofs define a specific
URI that means whatever the profile needs it to mean.

As I see it, it all comes down to sticking URIs someplace to trigger
rejection by existing/unaware software. It doesn't really matter where the
URI ends up, so not defining a new Method just pushes that URI into

I'm fine with either approach, but the spec tends to encourage shared (and
inappropriate IMHO) use of holder of key across profiles. So I did it that

-- Scott

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