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] Minutes: SSTC Conference Call (September 22nd, 2009)


Scott Cantor wrote on 2009-10-02:
> If you instead mean for this to be front channel, I still think it's
> difficult to pull off safely because the ability to assign the identifier
in
> reverse is really just reversing the role of the IdP and SP in the flow.
The
> "SP" has to become an IdP and issue what amounts to an assertion in order
> for the IdP to be able to validate the user's right to "be" that
identifier.

To elaborate on this point, what I think you're really after here would be
accomplished without any new spec bits, by inserting a reversed SSO exchange
in the middle of the outer exchange.

In other words...

1. EntityA -> AuthnRequest -> EntityB
2. EntityB authenticates user and realizes it's a new link.
3. EntityB saves off enough state to remember the initial request.
4. EntityB -> AuthnRequest -> EntityA
5. EntityA authenticates user
6. EntityA -> Response -> EntityB
7. EntityB recovers state and creates link.
8. EntityB -> Response -> EntityA

I don't see how you avoid what amounts to that, subject to whatever
optimizations might be possible.

And IMHO, it's a lot of extra work at an SP (which now becomes an IdP)
without any obvious benefit, but it isn't anything you couldn't do now if
you wanted.

-- Scott




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