Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-assertions-08.txt> (Assertion Framework for OAuth 2.0) to Proposed Standard

[Chuck Mortimore <[e-mail]>]

Correct.   That said no one has yet profiled it for holder of key

- cmort

On Dec 13, 2012, at 6:39 PM, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> wrote:


Oh, But the description of assertion generation in the document should not be limited by bear assertion, right?


Chuck Mortimore <[e-mail]<mailto:[e-mail]>> 写于 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, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>
> > 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 <[e-mail]<mailto:[e-mail]>> 写于 2012-12-14 10:08:34:
>
> > On Dec 13, 2012, at 4:30 PM, "[e-mail]<mailto:[e-mail]>" <zhou.
> [e-mail]<mailto:[e-mail]>
> > > 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 <[e-mail]<mailto:[e-mail]>> 写于 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, <[e-mail]<mailto:[e-mail]>> 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?
> > >
> > >
> > >
> > >
> > > [e-mail]<mailto:[e-mail]> 写于 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
> > > > [e-mail]<mailto:[e-mail]> mailing lists by 2012-12-24. Exceptionally,
> comments may be
> > > > sent to [e-mail]<mailto:[e-mail]> 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
> > > > [e-mail]<mailto:[e-mail]>
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > _______________________________________________
> > > OAuth mailing list
> > > [e-mail]<mailto:[e-mail]>
> > > https://www.ietf.org/mailman/listinfo/oauth