Oh, But the description of assertion generation in the document should not be limited by bear assertion, right?
Chuck Mortimore <cmortim...@salesforce.com> 写于 2012-12-14 10:34:13: > You want a holder of key pattern. The draft touches on it > > > The protocol parameters and processing rules defined in this document > are intended to support a client presenting a bearer assertion to an > authorization server. The use of holder-of-key assertions are not > precluded by this document, but additional protocol details would > need to be specified. > > So - if you want this, you should put forth a holder of key > profiling of this draft and see if there are any issues. The only > profiles we have thus far are saml and jwt bearer assertions. > > > - cmort > > On Dec 13, 2012, at 6:27 PM, "zhou.suj...@zte.com.cn" <zhou.suj...@zte.com.cn > > wrote: > > I am not sure if the following usecase http://www.ietf.org/mail- > archive/web/oauth/current/msg10233.html > could be supported by assertion framework， > We have some discussion in > http://www.ietf.org/mail-archive/web/oauth/current/msg10203.html > http://www.ietf.org/mail-archive/web/oauth/current/msg10198.html > > In my use case or in some other cases, assertions don't need > confidential protection, > basically STS don't have to authenticate a client before issueing > "assertion", if it could be called assertion here. > > Example,I trust my laywer, I may issue an "assertion" stating > delegation in advance, and send to the lawyer when it is needed, > it could be I give the assertion to a false lawyer, but it does not > matter, because the lawyer has to prove he knows some credential > corresponding to his ID, > who is delegated some rights. > > If assertion framework want to support this use case, then > generation of assertion should be relaxed, > otherwise new work is required to support the use case. > > > > Chuck Mortimore <cmortim...@salesforce.com> 写于 2012-12-14 10:08:34: > > > On Dec 13, 2012, at 4:30 PM, "zhou.suj...@zte.com.cn" <zhou. > suj...@zte.com.cn > > > wrote: > > > > > From the language, I got an impression that assertion is only > > generated by token service after clients presenting some credentials, > > there are may be some cases that "assertion" don't need client's > credential. > > e.g., Resource owner as a token service could generate "assertion" > > to a client he trusts, bu signing a statement that "This delegation > > is given to a client called clinet-id > > for doing something for me". > > > > So how does the STS trust the client? Presumably if it is trusted > > it has some level of authentication, yes? > > > > -cmort > > > > > > > > > > > > Chuck Mortimore <cmortim...@salesforce.com> 写于 2012-12-14 00:39:03: > > > > > 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, <zhou.suj...@zte.com.cn> 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? > > > > > > > > > > > > > > > oauth-boun...@ietf.org 写于 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 > > > > i...@ietf.org mailing lists by 2012-12-24. Exceptionally, > comments may be > > > > sent to i...@ietf.org 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 > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
