FYI, I have been writing HoK for JWT/JWS Token by introducing a new claim 'cid'.
=nat via iPhone Dec 14, 2012 11:56、"zhou.suj...@zte.com.cn" <zhou.suj...@zte.com.cn> のメッセ�`ジ: Yep, could do it soon later. Currently, I suggest a modification for "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." (in section 3 ) into "The token service is the assertion issuer, *it could be implemented in any entity besides client, e.g., Resource Owner, Authorization Server;* 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." Chuck Mortimore <cmortim...@salesforce.com> 写于 2012-12-14 10:44:05: > Correct. That said no one has yet profiled it for holder of key > > - cmort > > On Dec 13, 2012, at 6:39 PM, "zhou.suj...@zte.com.cn" < zhou.suj...@zte.com.cn > > wrote: > > 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 authenticationmechanism > > > > > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
