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] OpenID SimplePermissions and SAML constrained delegation


> In previous discussions we never really saw a browser SSO delegation
> profile all the way through.  Shib got as far as this:
> 
>
http://shibboleth.internet2.edu/docs/draft-cantor-saml-sso-delegation-01.pdf

So, for the record, that document should simply be treated as a stale input
into ID-WSF 2.0, and anything you can't do with WSF wasn't in scope of that
document.

Specifically, delegation of browser SSO was NOT in scope, so there's no
overlap between it and what you're describing here for OpenID.

In general, I haven't seen demand for the kind of blanket approach you're
describing, because delegation of rights is typically more fine-grained than
that.

At a single web-based app, supporting delegation can be an authorization
problem. What's harder is delegation of subsequent back-end communication by
that application, which WSF does support.

That said, if somebody wants to do this, it's trivial enough to use
confirmation data to do it. Bearer assertions can identify a delegate in the
embeddded NameID element, same as with holder of key. I just don't think it
gets a non-trivial app off the hook, because it still needs to include
policy over what the delegate can actually do vs. the real user. At that
point, it may as well just implement the delegation inside the application
by granting one user the ability to do things to resources owned by the
other.

-- Scott




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