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 <cmortimore@xxxxxxxxxxxxxx>
写于 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.sujing@xxxxxxxxxx> 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-bounces@xxxxxxxx 写于 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
> > ietf@xxxxxxxx mailing lists by 2012-12-24. Exceptionally, comments
may be
> > sent to iesg@xxxxxxxx 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@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/oauth
|