The language is simply meant to help illustrate how the framework might be used. How do you think it will restrict usage? How could it be improved?
-cmort On Dec 12, 2012, at 11:04 PM, <[email protected]<mailto:[email protected]>> wrote: In "section 3 The token service is the assertion issuer; its role is to fulfill requests from clients, which present various credentials, and mint assertions as requested, fill them with appropriate information, and sign them." As I understand, an assertion generated by a STS, is done flollowing thess steps: 1. Client presents credential and requests an assertion 2. STS generates assertion and sends to Client Correct? That may restrict the use cases that this assertion framework could support, is it a must? [email protected]<mailto:[email protected]> 写于 2012-12-11 02:33:57: > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'Assertion Framework for OAuth 2.0' > <draft-ietf-oauth-assertions-08.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > [email protected]<mailto:[email protected]> mailing lists by 2012-12-24. > Exceptionally, comments may be > sent to [email protected]<mailto:[email protected]> instead. In either case, please > retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This specification provides a framework for the use of assertions > with OAuth 2.0 in the form of a new client authentication mechanism > and a new authorization grant type. Mechanisms are specified for > transporting assertions during interactions with a token endpoint, as > well as general processing rules. > > The intent of this specification is to provide a common framework for > OAuth 2.0 to interwork with other identity systems using assertions, > and to provide alternative client authentication mechanisms. > > Note that this specification only defines abstract message flows and > processing rules. In order to be implementable, companion > specifications are necessary to provide the corresponding concrete > instantiations. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > OAuth mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
