ietf
[Top] [All Lists]

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

2012-12-14 11:27:52

On Dec 13, 2012, at 4:30 PM, 
"zhou(_dot_)sujing(_at_)zte(_dot_)com(_dot_)cn<mailto:zhou(_dot_)sujing(_at_)zte(_dot_)com(_dot_)cn>"
 
<zhou(_dot_)sujing(_at_)zte(_dot_)com(_dot_)cn<mailto:zhou(_dot_)sujing(_at_)zte(_dot_)com(_dot_)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 
<cmortimore(_at_)salesforce(_dot_)com<mailto:cmortimore(_at_)salesforce(_dot_)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(_dot_)sujing(_at_)zte(_dot_)com(_dot_)cn<mailto:zhou(_dot_)sujing(_at_)zte(_dot_)com(_dot_)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-bounces(_at_)ietf(_dot_)org<mailto:oauth-bounces(_at_)ietf(_dot_)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
ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org> mailing lists by 
2012-12-24. Exceptionally, comments may be
sent to iesg(_at_)ietf(_dot_)org<mailto:iesg(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org<mailto:OAuth(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth(_at_)ietf(_dot_)org<mailto:OAuth(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/oauth