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] Question re: SubjectConfirmation in Delegated Tokens (sstc-saml-delegation)

> Does this mean that the <saml:SubjectConfirmation> of the most recent
> delegate should replace any elements existing in the delegatable token
> or that they should be added to?

That's not really in scope, except to say that if there's a "chain" being
expressed, it's a logical assumption that the token is only supposed to be
used by the last link in the chain. But in general you put the subject
confirmations into the token that you want into the token. There's no way to
define it any more specifically without talking about a higher level

> So is the intent that a delegated token should contain a single
> <saml:SubjectConfirmation> element for the most recent delegate or that
> it should contain a <saml:SubjectConfirmation> element for each delegate
> and one for the original subject?

It doesn't make a lot of sense to have a token that can be used by anybody
in the chain but claim that there's a chain, because the actual chain would
depend on who's using it. But that's more of a common sense thing. At the
end of the day they're distinct constructs that mean different, but related,

I guess what I'm saying is, this is not a profile for delegation. It's a
profile for expressing a set of delegations that some other sequence of
token exchanges result in. The tokens that get issued each have the
"appropriate" content based on the semantics of those exchanges.

-- Scott

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