<internet-drafts@ietf.org> · Fri, 7 Sep 2012 07:13:53 -0700

> 

> (looking at v31 of the draft [1])

> 

> In "Authorization Code Grant" (section 4.1), when the ResourceOwner

> authorizes a `scope` that differs from the `scope` the Client requested,

> how does the Client find out the modified scope value?

The scope is sent in the access token. 
> 

> "Implicit Grant" addresses this by including a `scope` parameter
in the 

> Authorization Token Response (4.2.2).  So this is not a problem
for the 

> Implicit grant type.

Implicit grant is different from authorization request
in "authorization code grant",
the former is for access token, the latter is for
authorization code which is exchanged further for access token
> 

> But "Authorization Code Grant" defines no such parameter
for its 

> Authorization Response (4.1.2).  Also, nothing equivalent in
the 

> subsequent Access Token Response (4.1.4). 

There is scope included in seciotn 5.1.  
> 

> 

> I'm new to the list, so if this has been discussed previously, or
if 

> I'm missing something obvious, please just point me in the right 

> direction.

> 

> Otherwise, I would propose the addition of `scope` as a response 

> parameter in 4.1.2 (Authorization Response), for the purpose of 

> communicating, to the Client, the actual granted scope value, which

> could be different from the requested scope value.  It should
behave 

> the same as the `scope` response parameter defined for the Implicit

> Grant's "Access Token Response" in section 4.2.2.

> 

> -Lee

> 

> 

> [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-31

> 

> _______________________________________________

> 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

  http://tools.ietf.org/html/draft-richer-oauth-chain-00
A new version of I-D, draft-richer-oauth-chain-00.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-chain
Revision:	 00
Title:		 A Method of Bearer Token Redelegation and Chaining for OAuth 2
Creation date:	 2012-09-07
WG ID:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-chain-00.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-chain
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-chain-00

Abstract:
   This document provides a method for a resource server to present a
   token that it has received from a client back to its authorization
   server for the purposes of receiving a derivative token for use on
   another resource server in order to chain together service requests.

The IETF Secretariat

  http://tools.ietf.or=
g/html/draft-richer-oauth-chain-00
A new version of I-D, draft-richer-oauth-chain-00.txt=
=0Ahas been successfully submitted by Justin Richer and posted to the=0AIET=
F repository.=0A=0AFilename:=09 draft-richer-oauth-chain=0ARevision:=09 00=
=0ATitle:=09=09 A Method of Bearer Token Redelegation and Chaining for OAut=
h 2=0ACreation date:=09 2012-09-07=0AWG ID:=09=09 Individual Submission=0AN=
umber of pages: 8=0AURL:             http://www.ietf.org/internet-drafts/dr=
aft-richer-oauth-chain-00.txt=0AStatus:          http://datatracker.ietf.or=
g/doc/draft-richer-oauth-chain=0AHtmlized:        http://tools.ietf.org/html/d=
raft-richer-oauth-chain-00=0A=0A=0AAbstract:=0A   This document provide=
s a method for a resource server to present a=0A   token that it has receiv=
ed from a client back to its authorization=0A   server for the purposes of =
receiving a derivative token for use on=0A   another resource server in ord=
er to chain together service requests.=0A=0A=0A                            =
                                                      =0A=0A=0AThe IETF Sec=
retariat=0A=0A
  http://tools.ietf.org/html/draft-richer-oauth-chain-00
A new version of I-D, draft-richer-oauth-chain-00.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-chain
Revision:	 00
Title:		 A Method of Bearer Token Redelegation and Chaining for OAuth 2
Creation date:	 2012-09-07
WG ID:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-chain-00.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-chain
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-chain-00

Abstract:
   This document provides a method for a resource server to present a
   token that it has received from a client back to its authorization
   server for the purposes of receiving a derivative token for use on
   another resource server in order to chain together service requests.

The IETF Secretariat

  http://tools.ietf.org/html/draft-r=
icher-oauth-chain-00
A new ver=
sion of I-D, draft-richer-oauth-chain-00.txt=0Ahas been successfully submit=
ted by Justin Richer and posted to the=0AIETF repository.=0A=0AFilename:=09=
 draft-richer-oauth-chain=0ARevision:=09 00=0ATitle:=09=09 A Method of Bear=
er Token Redelegation and Chaining for OAuth 2=0ACreation date:=09 2012-09-=
07=0AWG ID:=09=09 Individual Submission=0ANumber of pages: 8=0AURL:        =
     http://www.ietf.org/internet-drafts/draft-richer-oauth-chain-00.txt=0A=
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-chain=
=0AHtmlized:        http://tools.ietf.org/html/draft-richer-oauth-chain-00=
=0A=0A=0AAbstract:=0A   This document provides a method for a resource serv=
er to present a=0A   token that it has received from a client back to its a=
uthorization=0A   server for the purposes of receiving a derivative token f=
or use on=0A   another resource server in order to chain together service r=
equests.=0A=0A=0A                                                          =
                        =0A=0A=0AThe IETF Secretariat=0A=0A
  http://tools.ietf.org/html/draft-richer-oauth-chain-00
A new version of I-D, draft-richer-oauth-chain-00.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-chain
Revision:	 00
Title:		 A Method of Bearer Token Redelegation and Chaining for OAuth 2
Creation date:	 2012-09-07
WG ID:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-chain-00.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-chain
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-chain-00

Abstract:
   This document provides a method for a resource server to present a
   token that it has received from a client back to its authorization
   server for the purposes of receiving a derivative token for use on
   another resource server in order to chain together service requests.

The IETF Secretariat

> The Client and the Resource Server need to obtain
this session key somehow. 

> Only two mechanisms exist: 

> 

> a) Key Transport 

> b) Key Agreement 

> 

> Here a key transport based mechanism is used and that's not uncommon.

I have no doubt about that.
My concern is may be there are some better ways to
do proof-of-posession, 
or proof-of-knowledge of keys. 
For example, as I wrote in  the review of draft-tschofenig-oauth-security-00:
 and
RS.
> 

> > Since distributing shared keys between AS and RS is already a

> cubersome work, 

> > sending key to client implies the key is only one time thing,
that

> will further increase the complexity. 

> > 

> An authentication and key exchange protocols is a complex thing. 

> No doubt about that. 

But Oauth is aimed at simple solutiion and better
user experience. 
An AKE and be complex, but some AKE can be simpler
than others, depending on requirements.

> 

> Keep in mind that this is a short-lived session key that's valid only

> for this client<->RS Instance.  The MAC Key is tied to
the Access Token,

> which is (hopefully!) tied to the client_id.  The MAC key is
a

> throw-away key.  Future access tokens would use *different* MAC
Keys.

> 

> Please take a look at the Kerberos Authenticator for prior art that

> explains how this works.

I have no doubt about how it works. 

> > For example, as I wrote in  the review of draft-tschofenig-oauth-

> security-00:

> > client send H(R) in token request to AS, AS includes the H(R)
in the token,

> > and client sends (token,R) to RS,

> > RS can verify the access capablity by recalculating H(R) and
checking access

> > toekn,

> > by feature of hash, RS can trust R provider,this method does
not use

> > pre-shared key between AS  and RS.

> 

> Sure, this works for a single request.  However it also means
you need

> to have the AS involved in *every* request because you cannot reuse
R.

> Another option would be:

> 

> AS sends an Access token, encrypted to the RS, and includes a MAC

> Session Key (Kms).  The Client can send the token, a Nonce (N),
and N

> encrypted with Kms ({N}Kms) to prove posession of Kms.  Of course
to

> protect replay attacks the RS has to keep a cache of all Nonces used

> under Kms.

Prove knowledge of key by encryption is not a good idea,as you mentioned,
for having to 
keep a cache.

> >> > Since distributing shared keys between AS and RS is
already a

> >> cubersome work,

> >> > sending key to client implies the key is only one time
thing, that

> >> will further increase the complexity.

> >> >

> >> An authentication and key exchange protocols is a complex
thing.

> >> No doubt about that.

> >

> > But Oauth is aimed at simple solutiion and better user experience.

> > An AKE and be complex, but some AKE can be simpler than others,
depending on

> > requirements.

> 

> Do you have a particular use-case in mind?

No. 

> -derek

> 

> -- 

>        Derek Atkins        
        617-623-3745

>        derek@ihtfp.com        
    www.ihtfp.com

>        Computer and Internet Security Consultant

> 

OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Subject:	New Version Notification for draft-richer-oauth-chain-00.txt
Date:	Fri, 7 Sep 2012 07:13:53 -0700
From:	<internet-drafts@ietf.org>
To:	<jricher@mitre.org>

Subject:=0A	New Ve= rsion Notification for=0A draft-richer-oauth-chain-00.txt
Date:	Fri, 7 Sep 2012 07= :13:53 -0700
From:	<= a rel=3D"nofollow" class=3D"yiv1609637444moz-txt-link-rfc2396E" ymailto=3D"= mailto:internet-drafts@ietf.org" target=3D"_blank" href=3D"mailto:internet-= drafts@ietf.org"><internet-drafts@ietf.org>
To:	<jricher@mitre.org>=0A

Subject:	New Version Notification for draft-richer-oauth-chain-00.txt
Date:	Fri, 7 Sep 2012 07:13:53 -0700
From:	<internet-drafts@ietf.org>
To:	<jricher@mitre.org>

Subject: <= /th>=0A	New Version Notification for=0A = draft-richer-oauth-chain-00.txt
Date:	Fri, 7 Sep 2012 07:13:53 -0700
From:	= <internet-drafts@ietf.org>
To:	<jricher@mitre.org>

Subject:	New Version Notification for draft-richer-oauth-chain-00.txt
Date:	Fri, 7 Sep 2012 07:13:53 -0700
From:	<internet-drafts@ietf.org>
To:	<jricher@mitre.org>

Subject:	[OAUTH-WG] prompt parameter for Auth= orization Request
Date:	Thu, 13 Sep 2012 20:36:13 +0000<= o:p>
From:	Lewis Adam-CAL022 <Adam.Lewis@motorola= solutions.com>
To:	oa= uth@ietf.org <oauth@ietf.org>