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] FW: [saml-dev] Constrained delegation

> I accept that the SAML 2.0 assertion structure is flexible enough for 
> our purposes.

I don't think anybody disputes the *ability* to communicate the semantic.
Obviously not by accident, it's the reason we proposed that addition at the
last minute.

> But I don't see how a relying party can assume very much just based on 
> the presence or absence of NameId in an assertion. That is where the
> fits in.

But I've yet to hear anybody offer an alternative assumption. I started off
writing that document based on the theory that even if I couldn't come up
with one, somebody else probably could. I think it's time they did or we
clarify the text and make life simple for ourselves.

> This was also one reason I focused on the constraints on SAML 
> authorities and Relying parties in my example:

I don't think either one obligates the relying party. It communicates what
the issuer is prepared to stand behind.

I think the relying party has all sorts of potential policies it could
choose to apply before it takes any action, including a deep dive into
things like the strength of the algorithms used to apply the key proof.

Also, I don't think us clarifying this semantic in core, or alternatively in
the confirmation method definitions in profiles, precludes anybody from
constructing an alternative interpretation using extensions. Defining the
semantics of the elements in the schema doesn't prevent people from using
the extension points to define different semantics.

-- Scott

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