Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

Yes, IANA can't act upon this until JWT is an RFC. If you point us to your draft defining new claims, however, I'd be glad review your proposed claims usage, if you're interested in that. Best wishes, -- Mike -Original Message

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

Well, OpenID Connect has a section register JWT claims so it can't be too premature: http://openid.net/specs/openid-connect-core-1_0.html#IANA However, private claims are often good enough for JWTs between a related AS and RS: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-19#section-4

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

On 4/25/2014 4:12 PM, Brian Campbell wrote: IHMO getting everyone to agree on the specific claims etc. needed for a standardized JWT access token is a bit of a rat's nest, which is why there's not been much progress in that area. I guess any IANA registry submissions for new JWT claims is p

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

To be clear, access tokens are opaque in OAuth and I don’t see any of us trying to change that in the general case. Particular authorization servers may use JWTs as an access token format, but that’s their private choice. I know of other authorization servers that have the access token value b

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

I think it is kind of assumed, yeah. And JWT as it is gives you everything you need for that as long as the AS and RS can agree on keys, JWE and/or JWS, and how the claims will look. I suspect that's what most deployments are doing with JWT access tokens today. We are, or offer JWS + JWT access tok

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

I am OK with that. On Apr 25, 2014, at 4:57 PM, Brian Campbell wrote: > I absolutely agree with always requiring both issuer and subject and that > doing so keeps the specs simpler and is likely to improve interoperability. > > However, without changing that, perhaps some of the text in the do

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

The only current draft that describes JWT as access tokens is the PoP draft: http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution That describes JWT access tokens and how to add PoP information. I don't think there is anything other than the JWT spec itself describing bearer JWT

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

I absolutely agree with always requiring both issuer and subject and that doing so keeps the specs simpler and is likely to improve interoperability. However, without changing that, perhaps some of the text in the document(s) could be improved a bit. Here's a rough proposal: Change the text of th

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

Thank you. Thats what I thought. Is it just assumed JWT would/might be used an access token format for Bearer token auth? Or is there another draft somewhere for that? Is anybody out there using JWS + JWT as a access token format? On 4/25/2014 2:59 PM, Brian Campbell wrote: draft-ietf-oau

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

Agreed. On Apr 25, 2014, at 3:07 PM, Mike Jones wrote: > I agree. We’d already discussed this pretty extensively and reached the > conclusion that always requiring both an issuer and a subject both kept the > specs simpler and was likely to improve interoperability. > > It’s entirely up to

[OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

draft-ietf-oauth-jwt-bearer is only about interactions (client authentication and JWT as an authorization grant) with the token endpoint and doesn't define JWT style access tokens. On Fri, Apr 25, 2014 at 12:51 PM, Bill Burke wrote: > Red Hat Keycloak [1] only supports basic auth for client aut

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

Red Hat Keycloak [1] only supports basic auth for client authentication as suggested in the OAuth 2 spec. But our access tokens are JWS signed JWTs. Does draft-ietf-oauth-jwt-bearer relate to OAuth Bearer token auth [2]? Or is there another document I should be following? I'd like to see w

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

I agree. We’d already discussed this pretty extensively and reached the conclusion that always requiring both an issuer and a subject both kept the specs simpler and was likely to improve interoperability. It’s entirely up to the application profile what the contents of the issuer and the subj

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

I believe, from the thread referenced earlier and prior discussion and draft text, that the WG has reached (rough) consensus to require the subject claim. So text that says "Subject element MUST NOT be included" isn't workable. It seems what's needed here is some better explanation of how, in case

Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples

I’m not sure how octal came up, as the examples all use JSON notation, which is decimal. (The word octet is a standard word for a value containing 8 bits, and has nothing to do with octal.) Hannes, we use JSON notation in the examples, rather than hexadecimal intentionally, as the specs are ba

Re: [OAUTH-WG] Session cookies in OAuth2 flow

For cross site request forgery you need to validate the value in state somehow. You could store the value in the browser session, or relate it somehow to session information in the server. Making up a random number in the request and checking that there is a random number in the response won'

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

MITREid Connect supports this mode, also (client authentication with a client-generated JWT assertion). We also have support for a subset of the JWT Bearer Assertion for renewing ID tokens, but as far as I know nobody's running that bit of code in reality and I can't guarantee it actually does

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

Oracle also has an implementation. Phil @independentid www.independentid.com phil.h...@oracle.com On Apr 25, 2014, at 3:13 AM, Antonio Sanso wrote: > Hi Torsten, > > Adobe also has an implementation. > > regards > > antonio > > On Apr 25, 2014, at 7:26 AM, Torsten Lodderstedt > wrote:

Re: [OAUTH-WG] Session cookies in OAuth2 flow

Hi John, Thanks a lot for your explanation! I am a bit confused regarding "state" parameter and cookies. I thought that "state" is included in redirection URI for user-agent and verified by client when Authorization server redirects user-agent back. It is a way to bind authorization request to

Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples

Note that the draft is showing an *octet sequence* with each individual octet being shown as decimal value. It doesn't state anything about using octal, the base-8 number system. Those octets also show unambiguously what is being base64url encoded (including the line endings via "13, 10") - no matt

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

Salesforce supports this > On Apr 25, 2014, at 6:11 AM, John Bradley wrote: > > The JWT bearer spec is used in Connect for authenticating clients with > asymmetric credentials. > > I don't know at the moment how many server implementations support that as it > is not MTI. > > I know it is on th

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

The JWT bearer spec is used in Connect for authenticating clients with asymmetric credentials. I don't know at the moment how many server implementations support that as it is not MTI. I know it is on the Ping roadmap but not currently in shipping product. John B. On Apr 25, 2014, at 9:25 AM,

Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples

So JWT 3.1 is based entirely on, and is just a subset of, JWS Appendix A.1. And I've got a test which validates that example in my JOSE library: https://bitbucket.org/b_c/jose4j/src/master/src/test/java/org/jose4j/jws/JwsUsingHmacSha256ExampleTest.java And here's

Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples

Hi Antonio good to see that others have run into the same issue before. I wonder why the carriage return and the line feed had been inserted. We either need some text to explain this in the example or to use an example that does not use carriage returns or line feeds. Ciao Hannes On 04/25/2014

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

Hi Sergey, no, your comment wasn't off-topic and I agree that more widespread support of the JWT spec will also have a positive impact on the JWT bearer implementation / deployment status. draft-ietf-oauth-jwt-bearer spec requires the JWT to be used in a specific way. It does, however, make sense

Re: [OAUTH-WG] Session cookies in OAuth2 flow

Yes the server can be stateless, though it may need to store client credentials and user to validate against, and refresh token grants etc. The "state" parameter allows the client to maintain some state information across the Oauth authorization request and response. Part of the use of that s

Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples

hi Hannes. On Apr 25, 2014, at 12:37 PM, Hannes Tschofenig wrote: > Hi all, > > As a document shepherd I have to verify the entire document and this > includes the examples as well. > > Section 3.1: > > You write: > > " > The following octet sequence is the UTF-8 representation of the JW

Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples

As far as I recall the spec example uses line separators and it can affect the output Thanks, Sergey On 25/04/14 11:37, Hannes Tschofenig wrote: Hi all, As a document shepherd I have to verify the entire document and this includes the examples as well. Section 3.1: You write: " The fol

[OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples

Hi all, As a document shepherd I have to verify the entire document and this includes the examples as well. Section 3.1: You write: " The following octet sequence is the UTF-8 representation of the JWT Header/JWS Header above: [123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 1

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

Hi Torsten, Adobe also has an implementation. regards antonio On Apr 25, 2014, at 7:26 AM, Torsten Lodderstedt mailto:tors...@lodderstedt.net>> wrote: Deutsche Telekom also has an implementation. regards, Torsten. Ursprüngliche Nachricht Von: Chuck Mortimore Datum:25.04.

Re: [OAUTH-WG] HOTK/POP/etc drafts

Hi Hannes On 25/04/14 10:44, Hannes Tschofenig wrote: Hi Sergey, On 04/25/2014 11:38 AM, Sergey Beryozkin wrote: Hopefully PoP model will not be made exclusive for JWT only, it won't be very OAuth2 friendly IMHO... Note that draft-richer-oauth-signed-http-request-01 doesn't use JWTs. I just u

Re: [OAUTH-WG] HOTK/POP/etc drafts

Hi Sergey, On 04/25/2014 11:38 AM, Sergey Beryozkin wrote: > Hopefully PoP model will not be made exclusive for JWT only, it won't be > very OAuth2 friendly IMHO... Note that draft-richer-oauth-signed-http-request-01 doesn't use JWTs. I just uses a JSON-based encoding of the parameters. I put a s

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

On 25/04/14 10:24, Hannes Tschofenig wrote: The implementation and deployment status of JWT is certainly good. For this write-up it would, however, be interesting to know what the implementation status of the JWT bearer assertion spec is. Was I off-topic ? Sorry about it, I thought it would be

Re: [OAUTH-WG] HOTK/POP/etc drafts

On 25/04/14 10:23, Hannes Tschofenig wrote: Good question. The architecture allows different mechanisms to be used for proof-of-possession between the client and the resource server. With the publication of draft-richer-oauth-signed-http-request-01 we have a version that uses a JOSE-based encodin

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

The implementation and deployment status of JWT is certainly good. For this write-up it would, however, be interesting to know what the implementation status of the JWT bearer assertion spec is. On 04/25/2014 10:50 AM, Sergey Beryozkin wrote: > On 24/04/14 23:41, Mike Jones wrote: >> I am aware of

Re: [OAUTH-WG] HOTK/POP/etc drafts

Good question. The architecture allows different mechanisms to be used for proof-of-possession between the client and the resource server. With the publication of draft-richer-oauth-signed-http-request-01 we have a version that uses a JOSE-based encoding. I have not had time to illustrate how the M

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

On 24/04/14 23:41, Mike Jones wrote: I am aware of these implementations: Microsoft Azure Active Directory: http://azure.microsoft.com/en-us/services/active-directory/ Google Service Account: https://developers.google.com/accounts/docs/OAuth2ServiceAccount I believe that Ping

Re: [OAUTH-WG] HOTK/POP/etc drafts

Hi Hannes Is the MAC token effort you were leading still on the map ? Thanks, Sergey On 24/04/14 20:42, Hannes Tschofenig wrote: Btw, the HTTP signature mechanism now also got published as http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01 I think we now have a pretty good c

Re: [OAUTH-WG] Session cookies in OAuth2 flow

Hi Antonio, Thanks for your quick answer. Important for me is that OAuth2 doesn't force to store client or user-agent states in the authorization server, so authorization server can be stateless and is not obligated to introduce the sessions at all. Regards, Andrei. > -Original Message

Re: [OAUTH-WG] Session cookies in OAuth2 flow

hi Andrei, AFAIU session cookie management is beyond the scope of the OAuth2 specification. regards antonio On Apr 24, 2014, at 6:39 PM, Andrei Shakirin wrote: > Hi, > > My name is Andrei Shakirin, I am working with OAuth2 implementation in Apache > CXF project. > Could you please help me t