Re: [OAUTH-WG] December 27, 2012 OAuth Release

[Dick Hardt]

Looks like I was not the only one that was reading "p0rn" when I saw "prn" … ;-)

On Dec 28, 2012, at 5:07 PM, Mike Jones  wrote:

> New versions of the OAuth JWT, JWT Bearer Profile, and Assertions specs have 
> been released incorporating feedback since IETF 85 in Atlanta.  The primary 
> change is changing the name of the “prn” claim to “sub” (subject) both to 
> more closely align with SAML name usage and to use a more intuitive name for 
> this concept.  (Also, see the related coordinated change to the OpenID 
> Connect specifications.)  The definition of the “aud” (audience) claim was 
> also extended to allow JWTs to have multiple audiences (a feature also in 
> SAML assertions).
>  
> An explanation was added to the JWT spec about why should be signed and then 
> encrypted.
>  
> The audience definition in the Assertions specification was relaxed so that 
> audience values can be OAuth “client_id” values.  Informative references to 
> the SAML Bearer Profile and JWT Bearer Profile specs were also added.
> This release incorporates editorial improvements suggested by Jeff Hodges, 
> Hannes Tschofenig, and Prateek Mishra in their reviews of the JWT 
> specification.  Many of these simplified the terminology usage.  See the 
> Document History section of each specification for more details about the 
> changes made.
>  
> This release is part of a coordinated release of JOSE, OAuth, and OpenID 
> Connect specifications.  You can read about the other releases here:  JOSE 
> Release Notes, OpenID Connect Release Notes.
>  
> The new specification versions are:
> ·http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06
> ·http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
> ·http://tools.ietf.org/html/draft-ietf-oauth-assertions-09
>  
> HTML formatted versions are available at:
> ·http://self-issued.info/docs/draft-ietf-oauth-json-web-token-06.html
> ·http://self-issued.info/docs/draft-ietf-oauth-jwt-bearer-04.html
> ·http://self-issued.info/docs/draft-ietf-oauth-assertions-09.html
>  
> -- Mike
>  
> ___
> 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

Re: [OAUTH-WG] December 27, 2012 OAuth Release

[William Mills]

Mike,

I've read through the JWT spec and I'm curious about something.  How do I 
specify a signature requirement as the server?  I didn't see it but I probably 
just missed it.  I'm thinking that with very little work a JWT can do 
everything that MAC does with greater flexibility, *BUT* the server needs to be 
able to require a signed usage.  Something I never liked about OAuth 1.0 is 
that the server must support all valid signature types, even PLAINTEXT, so I 
want to be able to avoid that.

It would require the client to be able to include client generated stuff in the 
JWT.

Thanks,

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

Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05

[Mike Jones]

I found the X.1252 definition.  It is:

6.18 claim [b-OED]: To state as being the case, without being able to give 
proof.

That seems both a bit vague, and actually incorrect, as the JWT may include 
proof of the veracity of the claim.  Please see the updated JWT draft for a 
hopefully more useful “Claim” definition.

Best wishes,
-- Mike

From: Mike Jones
Sent: Sunday, December 23, 2012 1:03 PM
To: Jeff Hodges; Nat Sakimura
Cc: IETF oauth WG
Subject: RE: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05

What is the X.1252 definition?

-- Mike

From: Nat Sakimura
Sent: ‎December‎ ‎23‎, ‎2012 ‎10‎:‎09‎ ‎AM
To: =JeffH
CC: Mike Jones, IETF oauth WG
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05

Re definition of 'claim', as JWT is supposed to be generic, it may be
better to go with the definition of X.1252 rather than OIDC.

=nat via iPhone

Dec 24, 2012 2:42、=JeffH 
mailto:jeff.hod...@kingsmountain.com>> のメッセージ:

>
> > Thanks for the replies, Jeff.  They make sense.  Particularly, thanks for
> > the "JSON Text Object" suggestion.
>
> welcome, glad they made some sense.
>
> similarly, if one employs JSON arrays, I'd define a "JSON text array".
>
>
> > For the "claims" definition, I'm actually prone to go with definitions based
> > on those in
> > http://openid.net/specs/openid-connect-messages-1_0-13.html#terminology -
> > specifically:
> >
> > Claim
> > A piece of information about an Entity that a Claims Provider asserts about
> > that Entity.
> > Claims Provider
> > A system or service that can return Claims about an Entity.
> > End-User
> > A human user of a system or service.
> > Entity
> > Something that has a separate and distinct existence and that can be
> > identified in context. An End-User is one example of an Entity.
>
> well, it seems to me, given the manner in which the JWT spec is written, one 
> can make the case that JWT claims in general aren't necessarily about an 
> Entity (as the latter term is used in the context of the OpenID Connect 
> specs), rather they're in general simply assertions about something(s). this 
> is because all pre-defined JWT claim types are optional and all JWT semantics 
> are left up to specs that profile (aka re-use) the JWT spec.
>
> HTH,
>
> =JeffH
>
> ___
> 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

Re: [OAUTH-WG] Review of draft-ietf-oauth-json-web-token-05

[Mike Jones]

Thanks for your review, Hannes.  Updates resulting from these comments are 
included in the latest drafts.

Thanks again,
-- Mike

From: Mike Jones
Sent: Monday, December 10, 2012 6:24 PM
To: 'Hannes Tschofenig'; oauth@ietf.org WG
Subject: RE: [OAUTH-WG] Review of draft-ietf-oauth-json-web-token-05


Thanks for the review comments, Hannes.  Replies are inline in green...



-- Mike



-Original Message-
From: oauth-boun...@ietf.org 
[mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Sunday, November 25, 2012 11:49 AM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Review of draft-ietf-oauth-json-web-token-05



Hi all,



I reviewed the document and I have a few questions (see below). I also think 
that this document has to wait for the JOSE documents to complete WGLC before 
it can be moved forward. It will have to wait anyway in the queue because of 
the normative dependency.



Agreed



- Header



In Section 3.1 you have an example of a JWT with an HMAC SHA-256 keyed message 
digest.

I would have assumed that the header contains the key id so that the receipient 
can actually decode it. I am sure you assume it implicitly determines it 
(somehow) but wouldn't it be better practice to additionally include the kid 
field to make it less ambigious?



I agree that in some contexts, including a Key ID would be important.  That 
being said, in other contexts, including some OAuth contexts, the key is 
implicitly known from context.  For instance, a shared symmetric key may be 
assigned to be used for an OAuth client at client registration time.  In that 
case, both the client and the server already know what key to use without 
needing a Key ID.  The same may true when using public key cryptography with an 
issuer that publishes a public key and a relying party that also publishes a 
public key.  Here again, the correct keys to be used can be determined via 
means external to the token itself.



- Namespace



The document defines a couple of claims. Quite naturally one wants to provide 
extension points since others will quite likely come up with new claims in the 
near future. The obvious approach would be to use an IANA registry to maintain 
uniqueness of the labels but without using a namespace declaration concept like 
XML does.



For some reason that does not seem to be enough to use IANA alone: the document 
introduces three types of claims, namely Reserved Claim Names, Public Claim 
Names, and Private Claim Names



No mechanism is stated how these claims can be differentiated but essentially 
everything is allowed. Section 2 ("Terminology") says that the claims that are 
not registered through IANA may be Domain Names, Object Identifiers (OIDs), 
UUIDs, etc.



Later in Section 4.2 it is said that public claims could be a URI, which is 
again different to what is said in Section 2.



Furthermore, Private Claims (as defined in Section 4.3) do not seem to have the 
requirement for uniqueness anymore even though Section 4 says that claim names 
in a JWT have to be unique.



The danger is obviously that two parties define claim names that have different 
semantic. This will lead to confusion. When claims with the same names are 
added to a JWT then, per specification, the receiver will have to fail.



If people are following the spec and using (IANA) reserved claim names, or 
public claim names (those containing a collision-resistant namespace), then the 
same names will always have the same semantics.  IANA is used for reserved 
claim names, where conflicts would otherwise be likely.  IANA is unnecessary 
for public claim names, because the collision-resistant namespace in the claim 
name prevents duplication.



Do we really need to support claims where uniqueness cannot be guaranteed?



Private claim names are there because in some contexts, the communication is 
between a fixed or constrained set of parties between whom private agreements 
are a perfectly acceptable namespace allocation solution.  Indeed, it wouldn't 
make much sense to register the meanings of claims with IANA that will only be 
used in a closed environment.



Can we decide on a few namespace concepts rather than leaving the list 
open-ended? What are the JOSE guys going to do about this issue?



The same namespace allocation strategy is being used by JOSE.



Btw, is it allowed to use JavaScript reserved keywords as claim names?



Yes



* "Mandatory to Implement"/"Mandatory to Understand"



Section 4 you write:



"

When used in a security-related context,

   implementations MUST understand and support all of the claims

   present; otherwise, the JWT MUST be rejected for processing.

"



In the same paragraph you write:



"

   Note

   

Re: [OAUTH-WG] Please review draft-ietf-oauth-json-web-token

[Mike Jones]

Thanks for your review, Prateek.  Updates resulting from these comments are 
included in the latest drafts.

Thanks again,
-- Mike

From: Mike Jones
Sent: Monday, December 10, 2012 5:51 PM
To: 'prateek mishra'; oauth@ietf.org
Subject: RE: [OAUTH-WG] Please review draft-ietf-oauth-json-web-token

Thanks for the comments, Prateek.  Replies inline in green...

-- Mike

From: oauth-boun...@ietf.org 
[mailto:oauth-boun...@ietf.org] On Behalf Of prateek mishra
Sent: Wednesday, November 07, 2012 7:16 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Please review draft-ietf-oauth-json-web-token

Hannes - here a couple of comments on the 05 draft -

(i) Section 4 -

[quote]
Note however, that the set of claims that a JWT must contain to be
considered valid is context-dependent and is outside the scope of this 
specification. When
used in a security-related context, implementations MUST understand and support 
all of the
claims present; otherwise, the JWT MUST be rejected for processing.
[\quote]

I am not sure what is being stated here. I understand the general sense of the 
paragraph but I found the
two sentences to be contradictory. The second sentence is also very strong - 
suppose we find
some private claim in a JWT that the recipient is unable to understand - 
perhaps an optional
attribute-value pair - MUST it then reject the token?
The strong language about "MUST understand" mirrors the same language in the 
JOSE specs.  As you probably know, there's an open issue being discussed by the 
JOSE working group about whether all header fields must be understood, or 
whether there will be a mechanism for signaling that some header fields may be 
safely ignored if not understood.  I suspect that if a change is made to the 
JOSE specs in this regard, a similar change might be applied here as well.

(ii) Section 6 -

[quote]

A plaintext

   JWT is a JWS using the "none" JWS "alg" header parameter value

   defined in JSON Web Algorithms (JWA) 
[JWA]; 
it is a JWS with an empty

   JWS Signature value.

[\quote]

It is later clarified that by "empty JWS Signature value" the draft means 
"empty string". That could
be added as a parenthetical remark at the end of the sentence. I actually spent 
some time looking
up the term "empty JWS Signature value" in the JWS specification.
I'll plan to apply this clarification in the next spec release.

Thanks,
prateek

Hi all,



you may have noticed that the JOSE working group had made good progress with 
their work and they are getting closer to a WGLC. This is a good point in time 
for us to review the JWT spec (see 
http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/). Please read 
through it in preparation for the meeting.



It would be good to hear who has implemented it and whether there is feedback 
on the document. Given the OpenID Connect interoperability tests there seem to 
be lots of implementations.



We would like to start a WGLC as soon as the WGLC for the JOSE documents  
starts.



Ciao

Hannes



___

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-WG] December 27, 2012 OAuth Release

[Mike Jones]

New versions of the OAuth JWT, JWT Bearer Profile, and Assertions specs have 
been released incorporating feedback since IETF 85 in Atlanta.  The primary 
change is changing the name of the "prn" claim to "sub" (subject) both to more 
closely align with SAML name usage and to use a more intuitive name for this 
concept.  (Also, see the related coordinated change to the OpenID Connect 
specifications.)  The definition of the "aud" 
(audience) claim was also extended to allow JWTs to have multiple audiences (a 
feature also in SAML assertions).

An explanation was added to the JWT spec about why should be signed and then 
encrypted.

The audience definition in the Assertions specification was relaxed so that 
audience values can be OAuth "client_id" values.  Informative references to the 
SAML Bearer Profile and JWT Bearer Profile specs were also added.
This release incorporates editorial improvements suggested by Jeff Hodges, 
Hannes Tschofenig, and Prateek Mishra in their reviews of the JWT 
specification.  Many of these simplified the terminology usage.  See the 
Document History section of each specification for more details about the 
changes made.

This release is part of a coordinated release of JOSE, OAuth, and OpenID 
Connect specifications.  You can read about the other releases here:  JOSE 
Release Notes, OpenID Connect Release 
Notes.

The new specification versions are:

*http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06

*http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

*http://tools.ietf.org/html/draft-ietf-oauth-assertions-09

HTML formatted versions are available at:

*http://self-issued.info/docs/draft-ietf-oauth-json-web-token-06.html

*http://self-issued.info/docs/draft-ietf-oauth-jwt-bearer-04.html

*http://self-issued.info/docs/draft-ietf-oauth-assertions-09.html

-- Mike

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

Re: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW: New Version Notification for draft-hardjono-oauth-resource-reg-00.txt

[Eve Maler]

On 28 Dec 2012, at 5:58 AM, "Anganes, Amanda L"  wrote:

> Hi Eve and Thomas,
> 
> On 12/27/12 8:11 PM, "Eve Maler"  wrote:
> 
>> Amanda, thanks for the lightning-fast comments back. A couple of additional 
>> notes on top of Thomas's response:
>> 
>> The "scope type" language is indeed new this time -- of course this whole 
>> modular spec is newly broken out, but the previous text from UMA's rev 05 
>> still said "scope". (There's a new member in the JSON description of a 
>> resource set that is called "type", but this is actually the resource set's 
>> type: different thing.) Maybe this should just be changed back to "scope" 
>> and "scope description", as we really do mean the same construct as in plain 
>> OAuth, although here it's enhanced with a machine-readable description, and 
>> it's mappable to resource sets that have been explicitly identified. One 
>> thing we've been learning lately is that terminology impedance mismatches 
>> are not worth the cost; this one is a recent back-sliding. :)
> 
> I think it would make much more sense to stick with "scope" and "scope 
> description". I assumed that you were trying to avoid collisions with OAuth 
> by changing it, but it sounds like that is not the case. 
> 
> There might be a better way to denote that these are enhanced scopes, but 
> "type" isn't quite right for that as it does imply a class or kind of thing 
> (to which many particular things might belong), rather than a special or 
> enhanced particular thing. 

Our experience so far is that enhanced versions of things should just use the 
name for the thing. Hence, in the UMA core spec we've finally started using 
OAuth terminology directly rather than sticking with our original names (which 
dated from OAuth 1.0). I for one find it a LOT clearer, now that OAuth's 
architecture has become more widely understood.

> 
>> 
>> Eve: Regarding the sentence "Without a specific resource set identifier path 
>> component, the URI applies to the set of resource set descriptions already 
>> registered." in Section 2.3: I suspect this can just be deleted entirely. 
>> It's redundant with the "List resource set registrations" bullet item just 
>> below, which literally shows the {rsid} component of the path being absent. 
>> This is the only supported method in this API that has no {rsid} path 
>> component.
>> Thomas: Resource set registration API:  If Alice (the RO) has already 
>> previously registered some resources at the AS, then Alice will already have 
>> a PAT token (and the AS knows about Alice, her PAT, her resource sets and 
>> scopes). If Alice comes back again with the same PAT and forgets to 
>> specificy the path component, we assume the AS is smart enough to figure out 
>> which sets Alice is refering to. Does this help? (or does it still read 
>> weirdly).
>> 
> These two explanations are very different. If Thomas's assessment is correct, 
> I would move that explanatory text up to the end of the paragraph starting 
> with "The authorization server MUST present an API…" and explain that the PAT 
> can also be used to figure out the {rsid} for any requests where it is left 
> off (implying that the {rsid} component MAY be left off of any of the 
> following API calls). Otherwise if Eve is correct and that additional caveat 
> is NOT meant to be there, I would suggest removing the phrase entirely as it 
> does seem to imply that {rsid} may be left off. 

I think Thomas might been thinking about a different issue we have faced in the 
past regarding URIs, which is the question of how protected-resource endpoints 
are disinguishable per resource owner. I won't deep-dive on that issue here to 
save confusion, but suffice to say I think we can remove the offending sentence.

> 
>> 
>> Regarding {rsreguri}: I do see it defined, in this same Section 2.3. 
>> Basically this notation is simply a device to allow for referring to a 
>> "resource set registration endpoint" (defined in the Terminology section) in 
>> the URIs here that serve as method templates. Is there a better way to do 
>> this?
> 
> Yes, it is defined but not actually used to describe the API paths. The 
> definition is fine but if it is there it should be used; for example the 
> "Create resource set description" path should change from "PUT 
> /resource_set/{rsid}" to "PUT {rsreguri}/resource_set/{rid}".

It's used just above the explanation: 

The authorization server MUST present an API for registering resource set 
descriptions at a set of URIs with the structure 
"{rsreguri}/resource_set/{rsid}", where the PAT provides sufficient context to 
distinguish between identical resource set identifiers assigned by different 
hosts.

Calls to this API are made to that endpoint, but don't include it in the 
in-band HTTP request syntax. Does this make sense, or am I crazy?...

> 
> --Amanda

Thanks again,

Eve


Eve Maler  http://www.xmlgrrl.com/blog
+1 425 345 6756 ht

[OAUTH-WG] "prn" -> "sub" :: draft-ietf-oauth-json-web-token-06.txt

[Dick Hardt]

Did I miss the discussion on this code breaking change?

I'm ok with the change, but would have expected more discussion / notice about 
a change such as this.

Before I run around and make edits to running code, I'd like to know if we are 
staying with this label.

-- Dick


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

Re: [OAUTH-WG] Review of Token Revocation draft

[Sergey Beryozkin]

Hi Torsten
On 27/12/12 18:22, Torsten Lodderstedt wrote:


Am 27.12.2012 10:57, schrieb Sergey Beryozkin:

sHi
On 25/12/12 12:41, Torsten Lodderstedt wrote:

Hi all,

any other opinion regarding having or not having a token type parameter?

I would like to go with #1 as it is rather late in the process to
(re-)introduce a mandatory parameter. And making it an optional
parameter (#4) seems not really useful to me.


ce
+1 to #4 - it might help optimizing the lookups. Example, refresh and
access token keys may be kept in different tables, so ideally revoking
a refresh token only would involve a definite lookup to the refresh
token table/etc only, same for access tokens.

Having said this, the optional parameter can probably be added later.

However, it made me think, should the client be able to say, "I'd like
to revoke this refresh token and the access token linked to this
refresh token", in other words, should the client be given an option
to optimize the revocation process ? Probably can be reviewed later too


Hi Sergey,

ok, got you. Thanks for the proposal. I agree with your assessment that
this can be added later. In my opinion, we generally need more
real-world implementation experience in order to optimize the protocol.
For the time being, I would like to have basic revocation support.



+1 again :-)

Thanks, Sergey


regards,
Torsten.



thanks, Sergey


regards,
Torsten.

The way I see it, we've got a few options:

1) Leave it as-is, with no field. Client/RS/whoever just sends the
token over and it's the AS's problem.
2) Define a required field with "access" and "refresh" value
semantics, and state that other values MAY be accepted by a given AS,
or defined by extension protocols. These extension values MUST be
fully qualified URIs.
3) Same as #2, but with IANA registry to allow for non-collision of
short names.
4) Define an optional field that the client MAY send as a hint to the
AS, and it's up to the AS to figure out if it makes any sense in the
context of the request. All bets are off as to the content of this
field, other than "it's a string".

There may be other approaches as well.

-- Justin

On 11/30/2012 04:28 PM, Anganes, Amanda L wrote:

Here is my review of the Toke Revocation draft
(http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):

Section 1. Introduction
First paragraph has the following definition in it: "A token is the
external representation of an access grant issued by a resource owner
to a particular client." This seems a bit odd to me. The OAuth2 spec
[1] defines "access token" as "An access token is a string
representing an authorization issued to the client." (section 1.4)
and "refresh token" as "credentials used to obtain access tokens
(section 1.5). Should this spec borrow similar language to be more
consistent?

Paragraph 2 "From an end-user's perception" should be "From an
end-user's perspective".

Section 2. Token Revocation
What is the reason for requiring the service provider to detect the
token type automatically? For our implementation, Access Tokens,
Refresh Tokens, and ID Tokens are all structured tokens (with unique
structures across the three types), and as such are stored in 3
separate database tables. In order to "detect" the token type, we
would need to run a get-by-value query across all three tables, check
if any of those queries returned anything, and then proceed to revoke
the token (if one was found). This does not seem ideal to me.

The spec says that "The authorization server first validates the
client credentials (in case of a confidential client) and verifies
whether the client is authorized to revoke the particular token."
What does this verification entail? Does it just mean that 1) the
client credentials must validate and 2) the token must belong to the
client requesting the revocation? If so I think the text should be
clarified to reflect that. Or are you thinking of a case where a
client might not be allowed to revoke its own tokens, via some kind
of scoping?

2.1 Cross Origin Support
Formatting looks a little off here, otherwise this section looks fine.

5. Security Considerations
Paragraph 3 (Malicious clients…): "Appropriate countermeasures, which
should be in place for the token endpoint as well, MUST be applied to
the revocation endpoint." These countermeasures should be referenced
to the proper section(s) of the OAuth core spec or Threat Model
document.

Paragraph 4 reads a bit oddly. Suggest following rewording:
"A malicious client may attempt to guess valid tokens on this
endpoint by making revocation requests against potential token
strings. According to this specification, a client's request must
contain a valid client_id, in the case of a public client, or valid
client credentials, in the case of a confidential client. The token
being revoked must also belong to the requesting client. If an
attacker is able to successfully guess a public client's client_id
and one of their tokens, or a private client's credentials and o

Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03

[Sergey Beryozkin]

Hi Torsten
On 27/12/12 18:02, Torsten Lodderstedt wrote:




Depending on the authorization server's revocation policy, the
revocation of a particular token may cause the revocation of related
tokens and the underlying authorization.
If the particular token is a refresh token and the authorization server
supports the revocation of access tokens, then the authorization server
SHOULD also invalidate all access tokens based on the same authorization
(seeImplementation Note <#impl>).



This implies that some ASs may, in theory at least, allow the client
to revoke the token but keep that specific client's authorization...


yep, it does. If this makes sense from the ASs perspective.


is it something OAuth2 allows ?

For example, what if the end user (as opposed to the client owning the 
token) goes and revokes a token for a given client via some UI console 
interacting with AS, I guess the end user expectations here is that the 
affected client won't be able to access this user's resources unless 
re-authorized again.


Why would it be different for a client revoking its access token ?

thanks, Sergey


regards,
Torsten.



Cheers, Sergey


Thoughts?

regards,
Torsten.

Am 26.12.2012 15:38, schrieb John Bradley:

We don't want to share grant information across multiple instances
of public client.

However we don't necessarily want to preclude multiple instances of
a private client, Though how the AS would tell them apart is a
interesting side question.

From a revocation point of view if you revoke the grant for one
instance of a client you revoke it for all, though for a public
client the grant is not doing anything anyway as the AS shield not
be pre approving based on the grant.

There are still some open questions about an extension to identify
client instances, though personally I prefer to have each instance
with it's own client ID.

The language around grants has always been a bit philosophical for
my taste.

If I recall correctly in the code flow the code is the
representation of the grant. In the implicit flow the grant is
implicit in the access token.
What construct (if any in the implicit case) is stored in the AS to
represent this is mostly left to the imagination of the implementer.

John B.


On 2012-12-25, at 8:24 AM, Torsten
Lodderstedt wrote:


Hi Mark,

thanks for reviewing the draft. Comments inline.

Am 02.12.2012 18:27, schrieb Mark Wubben:

The draft relies heavily on the definition "access grant", but no
definition is provided in the draft or RFC 6749. It's been my
interpretation that an "access grant" is the *fact* that a
resource owner has authorized a client (potentially scoped) access
to the protected resources. Once access is granted in this manner,
further access tokens may be obtained without explicit permission
by the end-user. That is, in the Protocol Flow there is no user
input between steps A and B.

That's correct.


In "1. Introduction" it is stated:


A
revocation request will invalidate the actual token and, if
applicable, other tokens based on the same access grant and the
access grant itself.

then, in "2. Token Revocation":


In the next step, the authorization server invalidates the token and
the respective access grant. If the particular token is a refresh
token and the authorization server supports the revocation of access
tokens, then the authorization server SHOULD also invalidate all
access tokens based on the same access grant

This implies that an access grant only applies to an app
authorized on a single device. If an app is installed on multiple
devices and the access grant is shared between both instances,
revoking device A's access token results in the unexpected
revocation of device B's token.

You raised an interesting point. Is it desirable to share an access
grant among different client instances? I would like to discuss
this topic in the working group.

If we assume it is desirable, how would the authorization process
look alike?

I would assume that as result of the authorization process of the
1st client instance, the authorization server stores an access
grant, which is identified by the client_id and the user_id of the
resource owner. Moreover, it creates a refresh token, which the 1st
client instance uses to obtain new access tokens. As this client is
public, the refresh token is the credential the intial client uses
to prove its identity.

How does the 2nd client instance join the party? I would assume the
2nd client to initiate another code grant type flow (using the same
client_id as the 1st client). I see two ways the authorization
server could process this process:

1) After authenticating the resource owner, the authorization
server finds the existing access grant for the client_id/user_id
combination and automatically issues tokens w/o further user
consent. Since the authorization server cannot authenticate the
client_id, a malicious client could obtain and abuse the access
grant of the legitimate client. That's why the security
considerati

Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03

[Justin Richer]

I'm fine with this approach, though I'd leave in a RECOMMEND for the 
refresh token -> access token cascading delete, since it will be a 
common one.


 -- Justin

On 12/26/2012 11:14 AM, Torsten Lodderstedt wrote:

Hi John,

thanks for your feedback.

After having thought through this topic again I came to the conclusion 
that I want to have a simple spec, which doesn't unnessarily restricts 
implementations. OAuth leaves so much freedom to implementors (for 
good reasons), which we should preserve.


What does this mean? I would like to focus on the revocation of the 
token actually passed to the revocation endpoint and leave the impact 
on other related tokens and the authorization itself to the 
authorization server's policy. The authorization server may 
incorporate the client type into its revocation policy.


My base assumption is that a client must be prepared to handle 
invalidation of tokens at any time. So from an interoperability 
perspective, it's not necessary to dictate a certain revocation policy 
to authorization servers.


Current text:

In the next step, the authorization server invalidates the token and 
the respective authorization. If the particular token is a refresh 
token and the authorization server supports the revocation of access 
tokens, then the authorization server SHOULD also invalidate all 
access tokens based on the same authorization (seeImplementation Note 
<#impl>).


The client MUST NOT use the token again after revocation.

Proposal:

In the next step, the authorization server invalidates the 
token. The client MUST NOT use this token again after revocation.


Depending on the authorization server's revocation policy, the 
revocation of a particular token may cause the revocation of related 
tokens and the underlying authorization.
If the particular token is a refresh token and the 
authorization server supports the revocation of access tokens, then 
the authorization server SHOULD also invalidate all access tokens 
based on the same authorization (seeImplementation Note <#impl>).


Thoughts?

regards,
Torsten.

Am 26.12.2012 15:38, schrieb John Bradley:

We don't want to share grant information across multiple instances of public 
client.

However we don't necessarily want to preclude multiple instances of a private 
client,  Though how the AS would tell them apart is a interesting side question.

 From a revocation point of view if you revoke the grant for one instance of a 
client you revoke it for all, though for a public client the grant is not doing 
anything anyway as the AS shield not be pre approving based on the grant.

There are still some open questions about an extension to identify client 
instances, though personally I prefer to have each instance with it's own 
client ID.

The language around grants has always been a bit philosophical for my taste.

If I recall correctly in the code flow the code is the representation of the 
grant.  In  the implicit flow the grant is implicit in the access token.
What construct (if any in the implicit case) is stored in the AS to represent 
this is mostly left to the imagination of the implementer.

John B.


On 2012-12-25, at 8:24 AM, Torsten Lodderstedt  wrote:


Hi Mark,

thanks for reviewing the draft. Comments inline.

Am 02.12.2012 18:27, schrieb Mark Wubben:

The draft relies heavily on the definition "access grant", but no definition is provided 
in the draft or RFC 6749. It's been my interpretation that an "access grant" is the 
*fact* that a resource owner has authorized a client (potentially scoped) access to the protected 
resources. Once access is granted in this manner, further access tokens may be obtained without 
explicit permission by the end-user. That is, in the Protocol Flow there is no user input between 
steps A and B.

That's correct.


In "1. Introduction" it is stated:


  A
revocation request will invalidate the actual token and, if
applicable, other tokens based on the same access grant and the
access grant itself.

then, in "2. Token Revocation":


  In the next step, the authorization server invalidates the token and
the respective access grant.  If the particular token is a refresh
token and the authorization server supports the revocation of access
tokens, then the authorization server SHOULD also invalidate all
access tokens based on the same access grant

This implies that an access grant only applies to an app authorized on a single 
device. If an app is installed on multiple devices and the access grant is 
shared between both instances, revoking device A's access token results in the 
unexpected revocation of device B's token.

You raised an interesting point. Is it desirable to share an access grant among 
different client instances? I would like to discuss this topic in the working 
group.

If we assume it is desirable, how would the authorization process look alike?

I would assume that as result of the authorization p

Re: [OAUTH-WG] Review of Token Revocation draft

[Justin Richer]

Sounds reasonable to me.

 -- Justin

On 12/25/2012 08:19 AM, Torsten Lodderstedt wrote:

Hi Peter,

your proposal sounds reasonable.

Since it involves a change to the interface spec (400 instead of 403 
in case of unauthorized access) I would like to ask the working group 
for feedback.


What do you think? I especially would like to gain feedback from 
implementors of the draft (e.g. Marius, Chuck, Justin).


regards,
Torsten.

Am 21.12.2012 23:15, schrieb Peter Mauritius:
During the last week I had the chance to implement the non optional 
features of the token revokation draft. I would be glad if the 
document would get a closer connection to the refrenced RFC6749 
regarding the error handling.


The draft states to use HTTP status 401 and 403 for certain error 
conditions. RFC6749 declares this as optional (OK, not for the 
Authorization header). The implemation of the token revokation 
endpoint in conjunction with a tokens endpoint would be much easier 
if there is a single way to handle exceptions which conforms to RFC6749.


Therefore I want to suggest to replace


Status code 401 indicates a
failed client authentication, whereas a status code 403 is used if
the client is not authorized to revoke the particular token.  For all
other error conditions, a status code 400 is used along with an error
response as defined insection 5.2  
. of [RFC6749  
].

with

The error presentation conforms to the defintion in section 5.2
of [RFC6749].

To express the status code 403 I suggest to use the error code 
"unauthorized_client" of RFC6749 in conjunction with status code 400. 
The additional error codes defined in the draft will remain of course.


Happy apocalypse ;-)
  Peter Mauritius


___
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

Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a URI?

[John Bradley]

Sorry yes, Google calls it cid.   Mike's TLA theory for JWT, JWE, JWS , JWK can 
be confusing at times.

On 2012-12-28, at 10:59 AM, Brian Campbell  wrote:

> I believe John meant to refer to Google's adding of the cid claim rather than 
> the prn claim.
> 
> 
> On Thu, Dec 27, 2012 at 5:53 PM, John Bradley  wrote:
> The discussion on the Connect call was that audience could be a literal or an 
> array.
> 
> example
> 
> "aud":["http://audiance1.com","http://audiance2.com";]
> 
> In some cases the token may want to have more than a single audience.  
> (anthropomorphic license)
> 
> in the simple case it would still be
> "aud":"http://audiance1.com";
> 
> While dynamic typing of variables is not my favourite thing in principal, I 
> am assured that this is common JSON syntax that people can deal with.
> 
> The idea is to standardize this rather than everyone coming up with their own 
> way around the restriction as google did by adding the prn claim.
> 
> At least this way if you only trust tokens with yourself as the audience you 
> have a easy way to check.
> 
> John B.
> 
> On 2012-12-27, at 7:57 PM, Anthony Nadalin  wrote:
> 
>> What do you mean by multi-valued and what are the semantics of multi-vale ?
>>  
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
>> John Bradley
>> Sent: Thursday, December 27, 2012 5:32 AM
>> To: Mike Jones
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a 
>> URI?
>>  
>> Agreed.
>>  
>> We need to clarify that the value of the audience claim can be multi valued 
>> as well. 
>>  
>> John B.
>>  
>> On 2012-12-26, at 10:43 PM, Mike Jones  wrote:
>> 
>> 
>> http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1 
>> currently says:
>>  
>> 
>>Audience  A URI that identifies the party intended to process the
>> 
>>   assertion.  The audience SHOULD be the URL of the Token Endpoint
>> 
>>   as defined in Section 3.2 of OAuth 2.0 [RFC6749].
>>  
>> I think that “URI” should be changed to “value”, since audience values in 
>> general need not be URIs.  In particular, in some contexts OAuth client_id 
>> values are used as audience values, and they need not be URIs.  Also, SAML 
>> allows multiple audiences (and indeed, the OAuth SAML profile is written in 
>> terms of “an audience value” – not “the audience value”), and so the generic 
>> Assertions spec should do likewise.
>>  
>> Thus, I would propose changing the text above to the following:
>>  
>>Audience  A value that identifies the parties intended to process the
>>   assertion.  An audience value SHOULD be the URL of the Token Endpoint
>>   as defined in Section 3.2 of OAuth 2.0 [RFC6749].
>>  
>> -- Mike
>>  
>> ___
>> 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

Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a URI?

[Brian Campbell]

I believe John meant to refer to Google's adding of the *cid* claim rather
than the *prn* claim.


On Thu, Dec 27, 2012 at 5:53 PM, John Bradley  wrote:

> The discussion on the Connect call was that audience could be a literal or
> an array.
>
> example
>
> "aud":["http://audiance1.com","http://audiance2.com";]
>
> In some cases the token may want to have more than a single audience.
> (anthropomorphic license)
>
> in the simple case it would still be
> "aud":"http://audiance1.com";
>
> While dynamic typing of variables is not my favourite thing in principal,
> I am assured that this is common JSON syntax that people can deal with.
>
> The idea is to standardize this rather than everyone coming up with their
> own way around the restriction as google did by adding the prn claim.
>
> At least this way if you only trust tokens with yourself as the audience
> you have a easy way to check.
>
> John B.
>
> On 2012-12-27, at 7:57 PM, Anthony Nadalin  wrote:
>
> What do you mean by multi-valued and what are the semantics of multi-vale ?
> 
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
> Of *John Bradley
> *Sent:* Thursday, December 27, 2012 5:32 AM
> *To:* Mike Jones
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Must the Audience value in the Assertions Spec
> be a URI?
> ** **
> Agreed.
> ** **
> We need to clarify that the value of the audience claim can be multi
> valued as well. 
> ** **
> John B.
> ** **
> On 2012-12-26, at 10:43 PM, Mike Jones 
> wrote:
>
>
> 
>
> http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1 
> currently
> says:
>  
>
>Audience  A URI that identifies the party intended to process the
>
>   assertion.  The audience SHOULD be the URL of the Token Endpoint
>
>   as defined in Section 3.2 
>  of 
> OAuth 2.0 [RFC6749 ].
>
>  
>
> I think that “URI” should be changed to “value”, since audience values in
> general need not be URIs.  In particular, in some contexts OAuth client_id
> values are used as audience values, and they need not be URIs.  Also, SAML
> allows multiple audiences (and indeed, the OAuth SAML profile is written in
> terms of “an audience value” – not “the audience value”), and so the
> generic Assertions spec should do likewise.
>  
> Thus, I would propose changing the text above to the following:
>  
>
>Audience  A value that identifies the parties intended to process the
>
>   assertion.  An audience value SHOULD be the URL of the Token 
> Endpoint
>
>   as defined in Section 3.2 
>  of 
> OAuth 2.0 [RFC6749 ].
>
>  
> -- Mike
>  
> ___
> 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

Re: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW: New Version Notification for draft-hardjono-oauth-resource-reg-00.txt

[Anganes, Amanda L]

Hi Eve and Thomas,

On 12/27/12 8:11 PM, "Eve Maler" mailto:e...@xmlgrrl.com>> 
wrote:

Amanda, thanks for the lightning-fast comments back. A couple of additional 
notes on top of Thomas's response:

The "scope type" language is indeed new this time -- of course this whole 
modular spec is newly broken out, but the previous text from UMA's rev 05 still 
said "scope". (There's a new member in the JSON description of a resource set 
that is called "type", but this is actually the resource set's type: different 
thing.) Maybe this should just be changed back to "scope" and "scope 
description", as we really do mean the same construct as in plain OAuth, 
although here it's enhanced with a machine-readable description, and it's 
mappable to resource sets that have been explicitly identified. One thing we've 
been learning lately is that terminology impedance mismatches are not worth the 
cost; this one is a recent back-sliding. :)

I think it would make much more sense to stick with "scope" and "scope 
description". I assumed that you were trying to avoid collisions with OAuth by 
changing it, but it sounds like that is not the case.

There might be a better way to denote that these are enhanced scopes, but 
"type" isn't quite right for that as it does imply a class or kind of thing (to 
which many particular things might belong), rather than a special or enhanced 
particular thing.


Eve: Regarding the sentence "Without a specific resource set identifier path 
component, the URI applies to the set of resource set descriptions already 
registered." in Section 2.3: I suspect this can just be deleted entirely. It's 
redundant with the "List resource set registrations" bullet item just below, 
which literally shows the {rsid} component of the path being absent. This is 
the only supported method in this API that has no {rsid} path component.
Thomas: Resource set registration API:  If Alice (the RO) has already 
previously registered some resources at the AS, then Alice will already have a 
PAT token (and the AS knows about Alice, her PAT, her resource sets and 
scopes). If Alice comes back again with the same PAT and forgets to specificy 
the path component, we assume the AS is smart enough to figure out which sets 
Alice is refering to. Does this help? (or does it still read weirdly).

These two explanations are very different. If Thomas's assessment is correct, I 
would move that explanatory text up to the end of the paragraph starting with 
"The authorization server MUST present an API…" and explain that the PAT can 
also be used to figure out the {rsid} for any requests where it is left off 
(implying that the {rsid} component MAY be left off of any of the following API 
calls). Otherwise if Eve is correct and that additional caveat is NOT meant to 
be there, I would suggest removing the phrase entirely as it does seem to imply 
that {rsid} may be left off.


Regarding {rsreguri}: I do see it defined, in this same Section 2.3. Basically 
this notation is simply a device to allow for referring to a "resource set 
registration endpoint" (defined in the Terminology section) in the URIs here 
that serve as method templates. Is there a better way to do this?

Yes, it is defined but not actually used to describe the API paths. The 
definition is fine but if it is there it should be used; for example the 
"Create resource set description" path should change from "PUT 
/resource_set/{rsid}" to "PUT {rsreguri}/resource_set/{rid}".

--Amanda


Eve

On 27 Dec 2012, at 4:37 PM, Thomas Hardjono 
mailto:hardj...@mit.edu>> wrote:

Thanks Amanda,
- Scope and types:  We went back and forth with regards to "scope type" and 
finally just used "type" with the assumption that the reader would know what we 
mean by it (ie. context dependent).  However, we're very open to going back to 
the previous language.
- Resource set registration: yes that sentence does read weirdly, will fix :-)

- The {rsreguri} URI component is defined but never used: hmm yes you are 
correct. Will fix this.
Thank you again.
cheers,
/thomas/
__
-Original Message-
From: Anganes, Amanda L [mailto:aanga...@mitre.org]
Sent: Thursday, December 27, 2012 4:57 PM
To: Thomas Hardjono; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW:
New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
Hi Thomas,
Here is some initial feedback.
Introduction paragraph 2:
Remove duplicate "with": "the OpenID Provider (OP) component is a
specialized version of an OAuth authorization server that brokers
availability of user attributes by dealing *with with* an ecosystem of
attribute providers (APs)."
Section 1.2 Terminology:
This is more of a comment for the UMA WG in general: "scope type" is an
unfortunate term (which appears in the UMA core draft [1] as well - if
memory serves the term used to be just "scope" but I couldn't find a
diff reference for when that chan

[OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-09.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

Title   : Assertion Framework for OAuth 2.0
Author(s)   : Brian Campbell
  Chuck Mortimore
  Michael B. Jones
  Yaron Y. Goland
Filename: draft-ietf-oauth-assertions-09.txt
Pages   : 22
Date: 2012-12-28

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-assertions-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-09


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bearer-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

Title   : JSON Web Token (JWT) Bearer Token Profiles for OAuth 
2.0
Author(s)   : Michael B. Jones
  Brian Campbell
  Chuck Mortimore
Filename: draft-ietf-oauth-jwt-bearer-04.txt
Pages   : 11
Date: 2012-12-28

Abstract:
   This specification defines the use of a JSON Web Token (JWT) Bearer
   Token as a means for requesting an OAuth 2.0 access token as well as
   for use as a means of client authentication.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bearer-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

Title   : JSON Web Token (JWT)
Author(s)   : Michael B. Jones
  John Bradley
  Nat Sakimura
Filename: draft-ietf-oauth-json-web-token-06.txt
Pages   : 24
Date: 2012-12-28

Abstract:
   JSON Web Token (JWT) is a compact URL-safe means of representing
   claims to be transferred between two parties.  The claims in a JWT
   are encoded as a JavaScript Object Notation (JSON) object that is
   used as the payload of a JSON Web Signature (JWS) structure or as the
   plaintext of a JSON Web Encryption (JWE) structure, enabling the
   claims to be digitally signed or MACed and/or encrypted.

   The suggested pronunciation of JWT is the same as the English word
   "jot".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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