All, After a request at IETF85 and a reminder from Hannes, I've posted a refresh of my original chaining document. No changes have been made in the refresh.
My current position is that this type of chaining (as defined in my earlier draft) is useful when you need to get a new token after crossing an administrative boundary. It is less useful when you have servers wanting to chain in essentially an act on behalf of case where a 1-leg solution is more desirable and 2-legs are costly. My plan is to work with Justin and reconcile with his work on http://tools.ietf.org/id/draft-richer-oauth-chain-00.txt > A new version of I-D, draft-hunt-oauth-chain-01.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. > > Filename: draft-hunt-oauth-chain > Revision: 01 > Title: Chain Grant Type for OAuth2 > Creation date: 2012-11-28 > WG ID: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-hunt-oauth-chain-01.txt > Status: http://datatracker.ietf.org/doc/draft-hunt-oauth-chain > Htmlized: http://tools.ietf.org/html/draft-hunt-oauth-chain-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-hunt-oauth-chain-01 > > Abstract: > This specification defines a method by which an OAuth protected > service, can use a received oauth token from its client, to in turn, > act as a client and access another OAuth protected service in a > 'chained' profile. Phil @independentid www.independentid.com phil.h...@oracle.com
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
