Below is a 'typical' ID-WSF flow, with those pieces that OAuth focuses on hilited in grey
As Robert points out, in ID-WSF the identity requestor (the WSC) first 'tries their luck' with an 'unauthorized request' to the identity attribute provider (the WSP). If this request is denied because of the alck of user consent, it's then that the WSP and the WSC engage in an interaction dance in order to get that consent - this set of messages logically identical to the OAuth flow.
OAuth would point to XRDS as providing the discovery component, but it 's not clear to me how to reconcile OAuth's existing static trust model with the possibility of real-time discovery? George?
4 comments:
Have you looked at the proposed ScalableOAuth Extension ?
http://wiki.oauth.net/ScalableOAuth
in particular the additional authorization flow.
Hi Praveen, I hadnt looked at it in detail, but I was aware of it. I referred to it in the original doc as
"New functionality for token management (e.g. Renew, revoke, etc) is work in progress"
I'll add a link in the paper (if you agree that this is an accurate description?)
thanks
paul
Hi Paul,
yes - there is a work in progress to convert this into a real spec (http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html) but at this time the wiki page (http://wiki.oauth.net/ScalableOAuth) is more easy to read and understand.
thanks
Praveen
In addition the standard OAuth flow allows for the SP/WSC to try and get the attribute from the SP in an "un-authorized" state. If the resource requires authorization, the SP sends back a HTTP 401 and requests authorization (section 5.4.2 of the core spec).
Post a Comment