Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0

[Anthony Nadalin]

I’m OK with the 
https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
 but not sure that 
https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
 is a good starting point as we would want a more generic solution for PoP 
tokens in general


From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, August 16, 2016 11:45 AM
To: Hannes Tschofenig 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0

Just a friendly reminder that the 'deadline' for this call for adoption is 
tomorrow.

According to the minutes from 
Berlin,
 13 people were in favor of adopting OAuth 2.0 Token Binding and 0 were against.

On Wed, Aug 3, 2016 at 1:45 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,

this is the call for adoption of the 'OAuth 2.0 Token Binding' document
bundle* following the positive call for adoption at the recent IETF
meeting in Berlin.

Here are the links to the documents presented at the last IETF meeting:
https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00

Please let us know by August 17th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Derek

*: We will find out what the best document structure is later, i.e.,
whether the content should be included in one, two or multiple documents.


___
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] Call for adoption: Token Binding for OAuth 2.0

[Brian Campbell]

Just a friendly reminder that the 'deadline' for this call for adoption is
tomorrow.

According to the minutes from Berlin
, 13 people
were in favor of adopting OAuth 2.0 Token Binding and 0 were against.

On Wed, Aug 3, 2016 at 1:45 AM, Hannes Tschofenig  wrote:

> Hi all,
>
> this is the call for adoption of the 'OAuth 2.0 Token Binding' document
> bundle* following the positive call for adoption at the recent IETF
> meeting in Berlin.
>
> Here are the links to the documents presented at the last IETF meeting:
> https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
> https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
>
> Please let us know by August 17th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Ciao
> Hannes & Derek
>
> *: We will find out what the best document structure is later, i.e.,
> whether the content should be included in one, two or multiple documents.
>
>
> ___
> 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] JWS JWT Access Tokens and resource audiences

[Sergey Beryozkin]

Hi Brian

Thanks, 'cid' is a proper compact name :-), I've made our code 
configurable - to support reporting a client_id property either as a 
'client_id' or 'cid' claim.


Cheers, Sergey

On 12/08/16 23:30, Brian Campbell wrote:

Yeah, the client typically isn't the/an audience of an access token. The
AT is opaque to the client and the client never processes or validates
it. So aud would have the resource(s) and something else could carry the
client id.

FWIW, token exchange is looking to define and register "cid" as a JWT
claim for the client identifier:
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05#section-4.3

On Fri, Aug 12, 2016 at 4:13 AM, Sergey Beryozkin mailto:sberyoz...@gmail.com>> wrote:

Hi,


After updating my earlier code (where 'client_id' was set as the
standard JWT access token 'aud' property) to use 'aud' to represent
the resource audiences I'm now thinking how to represent a
'client_id' in this token.

For now if I'm using a 'client_id' claim, to be consistent with a
standard token introspection response.

The other thing is how to represent a name of the user who
authorized the code grant which was exchanged for this token.

Again I'm using a "username" claim, to be consistent with a standard
token introspection response.

Also thinking, what value if any a 'sub' claim in such a token
should have. I'm setting it to a unique user identifier (similarly
to IdToken).

Any comments are welcome

Sergey


On 11/08/16 23:30, Sergey Beryozkin wrote:

Hi John
On 11/08/16 23:24, John Bradley wrote:

I think most people put the a resource URI in the aud.

Connect uses the client ID as that is bit more stable than
trying to
use a redirect URI when there could be multiple ones.
Given that a resource server doesn’t typically have a
client_id the
resource uri make a reasonable value.

You could put it in resource if you like, but that is
probably not
what others are doing.

I was suspecting I might be on my own here yes :-)


It may be time for a interoperable JWT access token profile
of some sort.


+1

We keep getting close with some of the PoP stuff but only
specify parts.


Thanks, Sergey


John B.

On Aug 11, 2016, at 6:16 PM, Sergey Beryozkin
mailto:sberyoz...@gmail.com>>
wrote:

Hi All

Awhile back I was asking why would self-contained JWS
JWT access
tokens would be used (as opposed to JWE JWTs), my
concern was that
anyone with a JWT library can read this token's content
- but as I
was explained that should not be a problem if such a JWS
JWT token
contains non-sensitive information. Besides, in some
cases, it gives
RS an option to validate this JWS JWT locally, without
having to make
a remote validation call.

So I've started experimenting and the immediate question
I have is
this one: which claim should one use to represent a
resource server
audience to get the most inter-operable RS level
validation logic ?

For example, a given RS may talk to different 3rd party
authorization
servers, say AS1 (vendor1) and AS2 (vendor2), and either
AS1 or AS2
JWS JWT tokens that this RS validates locally should
ideally use the
same claim to represent a resource audience. RS
validation logic is
written independently (without using AS1 or AS2 aware
validation
libraries).

We do expect such requirements coming in our
deployments. AS1 &
independent validation logic is already in use. Just a
matter of time
before AS2 is introduced.

So JWT has a standard 'aud' claim - but I believe this
should be a
'clientId' of the client a token is issued to, similarly
to the way
the 'aud' is treated in IdToken.

So I've prototyped the code where JWT has these claims:

"aud" = clientId
"resource" = 'http://myResourceServer'

where 'resource' is borrowed from OAuth2 Resource
Indicators draft
and represent a specific RS target address, the resource
server
audience.

Am I on the right path ? How wo