Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 14 Jan 2011 23:32:00 -0700

One of the main problems with OAuth in general has always been the unsanitary mix of authorization and authentication ("it's an authentication protocol... authorization protocol... authentication protocol" [1]). It has always been a confusing mess. The work on 2.0 has provided a valuable abstraction and separation of the two components, especially the recent document split. In addition, the recent work on the bearer token document and the MAC token type have raised issues about OAuth and its relationship with HTTP authentication.

I would like to suggest we drop the 'OAuth2' WWW-Authenticate header completely from the specification for the following reasons:

1.       Draft oauth-v2 is clearly not an authentication protocol. It *utilizes* client authentication. It offers one fully defined method for client authentication (which is basically HTTP Basic+), provides a half-baked client assertion authentication hook, and leaves all end-user authentication out of scope.

2.       The WWW-Authenticate header has absolutely no value, interoperability-wise or otherwise. Discovery was rules to be beyond the scope of this specification. Having a protected resource declare it supports authentication using some unspecified credentials obtained using some unspecified client flow is confusing at best. In the future, an interoperable discovery mechanism will be needed to allow clients to interact with completely unknown protected resources, but this has been consistently ruled to be premature standardization at this point.

3.       OAuth is agnostic to token authentication, and we already have three discrete token type proposals - all with active deployment plans in the coming months. Two of these methods have already defined a full HTTP authentication scheme (even if the bearer token specification has not yet been updated to change its scheme name).

4.       HTTP *authentication* is not an appropriate facility to negotiate *authorization*. OAuth authorization discovery can be added to HTTP authentication schemes as attributes, but makes no sense as a scheme of its own. The issues we are having with 'realm' is one of the examples showing that we are abusing the header.

5.       Again, as specified, it adds no value and I am not aware of any existing OAuth 1.0a implementation making use of the response header for client interoperability (yes, many include it, but how many clients actually rely on it, and if they do, how?).

For these reasons I would like to suggest we:

1.       Drop the WWW-Authenticate header definition and OAuth2 scheme from the specification, leaving it up to each token type to define its own authentication flow. In the future, a comprehensive discovery specification should define a new HTTP response header for providing discovery information. I have suggested using Link: rel='authorization' as a simple yet powerful solution.

2.       Rename the document to 'The OAuth 2.0 Authorization Protocol' to make it clear what this document is really about.

Comments? Counter argument?

EHL

[1] http://www.youtube.com/watch?v=0IBZocFkXGY

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 16 Jan 2011 19:59:36 +0100

wouldn't that mean to drop section 6 completely?

regards,
Torsten.

Am 15.01.2011 07:32, schrieb Eran Hammer-Lahav:
>
> One of the main problems with OAuth in general has always been the 
> unsanitary mix of authorization and authentication ("it's an 
> authentication protocol... authorization protocol... authentication 
> protocol" [1]). It has always been a confusing mess. The work on 2.0 
> has provided a valuable abstraction and separation of the two 
> components, especially the recent document split. In addition, the 
> recent work on the bearer token document and the MAC token type have 
> raised issues about OAuth and its relationship with HTTP authentication.
>
> I would like to suggest we drop the 'OAuth2' WWW-Authenticate header 
> completely from the specification for the following reasons:
>
> 1.Draft oauth-v2 is clearly not an authentication protocol. It 
> **utilizes** client authentication. It offers one fully defined method 
> for client authentication (which is basically HTTP Basic+), provides a 
> half-baked client assertion authentication hook, and leaves all 
> end-user authentication out of scope.
>
> 2.The WWW-Authenticate header has absolutely no value, 
> interoperability-wise or otherwise. Discovery was rules to be beyond 
> the scope of this specification. Having a protected resource declare 
> it supports authentication using some unspecified credentials obtained 
> using some unspecified client flow is confusing at best. In the 
> future, an interoperable discovery mechanism will be needed to allow 
> clients to interact with completely unknown protected resources, but 
> this has been consistently ruled to be premature standardization at 
> this point.
>
> 3.OAuth is agnostic to token authentication, and we already have three 
> discrete token type proposals -- all with active deployment plans in 
> the coming months. Two of these methods have already defined a full 
> HTTP authentication scheme (even if the bearer token specification has 
> not yet been updated to change its scheme name).
>
> 4.HTTP **authentication** is not an appropriate facility to negotiate 
> **authorization**. OAuth authorization discovery can be added to HTTP 
> authentication schemes as attributes, but makes no sense as a scheme 
> of its own. The issues we are having with 'realm' is one of the 
> examples showing that we are abusing the header.
>
> 5.Again, as specified, it adds no value and I am not aware of any 
> existing OAuth 1.0a implementation making use of the response header 
> for client interoperability (yes, many include it, but how many 
> clients actually rely on it, and if they do, how?).
>
> 1.Drop the WWW-Authenticate header definition and OAuth2 scheme from 
> the specification, leaving it up to each token type to define its own 
> authentication flow. In the future, a comprehensive discovery 
> specification should define a new HTTP response header for providing 
> discovery information. I have suggested using Link: 
> rel='authorization' as a simple yet powerful solution.
>
> 2.Rename the document to 'The OAuth 2.0 Authorization Protocol' to 
> make it clear what this document is really about.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 16 Jan 2011 15:05:35 -0700

No, it will just be very short giving an introduction to how to use tokens in general, how to define token types, and will include two examples for bearer tokens and mac tokens.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Sunday, January 16, 2011 11:00 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme

regards,
Torsten.

Draft oauth-v2 is clearly not an authentication protocol. It *utilizes* client authentication. It offers one fully defined method for client authentication (which is basically HTTP Basic+), provides a half-baked client assertion authentication hook, and leaves all end-user authentication out of scope.

The WWW-Authenticate header has absolutely no value, interoperability-wise or otherwise. Discovery was rules to be beyond the scope of this specification. Having a protected resource declare it supports authentication using some unspecified credentials obtained using some unspecified client flow is confusing at best. In the future, an interoperable discovery mechanism will be needed to allow clients to interact with completely unknown protected resources, but this has been consistently ruled to be premature standardization at this point.

OAuth is agnostic to token authentication, and we already have three discrete token type proposals - all with active deployment plans in the coming months. Two of these methods have already defined a full HTTP authentication scheme (even if the bearer token specification has not yet been updated to change its scheme name).

HTTP *authentication* is not an appropriate facility to negotiate *authorization*. OAuth authorization discovery can be added to HTTP authentication schemes as attributes, but makes no sense as a scheme of its own. The issues we are having with 'realm' is one of the examples showing that we are abusing the header.

Again, as specified, it adds no value and I am not aware of any existing OAuth 1.0a implementation making use of the response header for client interoperability (yes, many include it, but how many clients actually rely on it, and if they do, how?).

Drop the WWW-Authenticate header definition and OAuth2 scheme from the specification, leaving it up to each token type to define its own authentication flow. In the future, a comprehensive discovery specification should define a new HTTP response header for providing discovery information. I have suggested using Link: rel='authorization' as a simple yet powerful solution.

Rename the document to 'The OAuth 2.0 Authorization Protocol' to make it clear what this document is really about.

EHL

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: William Mills <[email-masked]>
Date: Tue, 18 Jan 2011 08:43:34 -0800

As long as we can do the discovery in band and it doesn't require major differences in-band I'm OK.  I spinning back up on the SASL mechanism (now that I finally was allowed to opensource it), and my current in-band discovery is pretty clean using WWW-Authenticate.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Friday, January 14, 2011 10:32 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 18 Jan 2011 23:22:01 -0700

Can you provide an example HTTP response header showing how you provide this discovery information? It would be helpful to think about solutions.

EHL

From: William Mills [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 8:44 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme

EHL

---

From: Subbu Allamaraju <[email-masked]>
Date: Tue, 18 Jan 2011 22:43:24 -0800

Could you clarify what the "confusing mess" part is? The cited reference [1] is not useful.

It is good to adhere to the challenge-response model of 2617 for wider interoperability and discoverability (yes, WWW-Authenticate with a well-known scheme name helps discovery and lack thereof reduces protocol visibility).

Subbu

On Jan 14, 2011, at 10:32 PM, Eran Hammer-Lahav wrote:

> One of the main problems with OAuth in general has always been the unsanitary mix of authorization and authentication (“it’s an authentication protocol… authorization protocol… authentication protocol” [1]). It has always been a confusing mess. The work on 2.0 has provided a valuable abstraction and separation of the two components, especially the recent document split. In addition, the recent work on the bearer token document and the MAC token type have raised issues about OAuth and its relationship with HTTP authentication.
>  
> I would like to suggest we drop the ‘OAuth2’ WWW-Authenticate header completely from the specification for the following reasons:
>  
> 3.       OAuth is agnostic to token authentication, and we already have three discrete token type proposals – all with active deployment plans in the coming months. Two of these methods have already defined a full HTTP authentication scheme (even if the bearer token specification has not yet been updated to change its scheme name).
> 4.       HTTP *authentication* is not an appropriate facility to negotiate *authorization*. OAuth authorization discovery can be added to HTTP authentication schemes as attributes, but makes no sense as a scheme of its own. The issues we are having with ‘realm’ is one of the examples showing that we are abusing the header.
> 1.       Drop the WWW-Authenticate header definition and OAuth2 scheme from the specification, leaving it up to each token type to define its own authentication flow. In the future, a comprehensive discovery specification should define a new HTTP response header for providing discovery information. I have suggested using Link: rel=’authorization’ as a simple yet powerful solution.
> 2.       Rename the document to ‘The OAuth 2.0 Authorization Protocol’ to make it clear what this document is really about.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 19 Jan 2011 00:13:54 -0700

Hi Subbu,

> -----Original Message-----
> From: Subbu Allamaraju [mailto:[email-masked]]
> Sent: Tuesday, January 18, 2011 10:43 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG

It was not meant to be useful... :-)
 
> It is good to adhere to the challenge-response model of 2617 for wider
> interoperability and discoverability (yes, WWW-Authenticate with a well-
> known scheme name helps discovery and lack thereof reduces protocol
> visibility).

There are two separate issues here. First, whether the HTTP authentication model with its challenge response architecture is suitable for OAuth (authorization). Second, if the currently defined response header field provides any level of interoperability. My answer is no to both. I'll explain.

OAuth is an authorization protocol not an authentication protocol. With the exception of the client password credentials passed in the form-encoded body, the protocol is completely authentication agnostic for both client authentication and end-user login. Add to that the recent separation of the token authentication schemes, and you get a clean and well defined authorization model.

A client using a token has to answer two questions: how to obtain authorization and how to use the provided authorization to access the protected resource. As currently specified, the header answers neither. In addition, for this to be a challenge response protocol, the client response must match the challenge which is not possible if the response can use different schemes based on the token type issued. That has proven very confusing to people on this list.

The only case a client is going to encounter the WWW-Authenticate header is when making an unauthenticated request (the three error codes provided add little to no value on top of the existing HTTP status codes). The only time that will happen is when the client is unfamiliar with the server. In such a case, the protocol as specified provides no further steps. The resource server is saying 'I support OAuth2' but implicitly saying 'and good luck figuring out what to do next'. For this to provide any actual interoperability at this level, the header must provide the supported profiles, endpoints, extensions, scope, etc. None of that is currently available.

This means the header is defined solely as a potential future extension point for discovery, which brings me back to the first issue. The WWW-Authenticate header is not the right place to provide authorization server discovery information. I think our inability to fit 'realm' into our framework shows how the HTTP authentication headers are not meant for this.

EHL
 
> unsanitary mix of authorization and authentication ("it's an authentication
> protocol... authorization protocol... authentication protocol" [1]). It has always
> been a confusing mess. The work on 2.0 has provided a valuable abstraction
> and separation of the two components, especially the recent document split.
> In addition, the recent work on the bearer token document and the MAC
> token type have raised issues about OAuth and its relationship with HTTP
> authentication.
> >
> > 1.       Draft oauth-v2 is clearly not an authentication protocol. It *utilizes*
> client authentication. It offers one fully defined method for client
> authentication (which is basically HTTP Basic+), provides a half-baked client
> assertion authentication hook, and leaves all end-user authentication out of
> scope.
> > 2.       The WWW-Authenticate header has absolutely no value,
> interoperability-wise or otherwise. Discovery was rules to be beyond the
> scope of this specification. Having a protected resource declare it supports
> authentication using some unspecified credentials obtained using some
> unspecified client flow is confusing at best. In the future, an interoperable
> discovery mechanism will be needed to allow clients to interact with
> completely unknown protected resources, but this has been consistently
> ruled to be premature standardization at this point.
> > 3.       OAuth is agnostic to token authentication, and we already have three
> discrete token type proposals - all with active deployment plans in the
> coming months. Two of these methods have already defined a full HTTP
> authentication scheme (even if the bearer token specification has not yet
> been updated to change its scheme name).
> > 4.       HTTP *authentication* is not an appropriate facility to negotiate
> *authorization*. OAuth authorization discovery can be added to HTTP
> authentication schemes as attributes, but makes no sense as a scheme of its
> own. The issues we are having with 'realm' is one of the examples showing
> that we are abusing the header.
> > 5.       Again, as specified, it adds no value and I am not aware of any existing
> OAuth 1.0a implementation making use of the response header for client
> interoperability (yes, many include it, but how many clients actually rely on it,
> and if they do, how?).
> >
> > 1.       Drop the WWW-Authenticate header definition and OAuth2 scheme
> from the specification, leaving it up to each token type to define its own
> authentication flow. In the future, a comprehensive discovery specification
> should define a new HTTP response header for providing discovery
> information. I have suggested using Link: rel='authorization' as a simple yet
> powerful solution.
> > 2.       Rename the document to 'The OAuth 2.0 Authorization Protocol' to

---

From: Subbu Allamaraju <[email-masked]>
Date: Tue, 18 Jan 2011 23:36:53 -0800

> A client using a token has to answer two questions: how to obtain authorization and how to use the provided authorization to access the protected resource. As currently specified, the header answer…

I agree about the separation, but a better fix is to name the protocols that the client can use for each step as part of this header. In any case, 401 responses are required (a MUST in 2616) to have a WWW-Authenticate header with a scheme. Dropping the header is not a choice that the OAuth draft or can/should make. Leaving the scheme name choice to each implementation would be confusing to the community.

> The only case a client is going to encounter the WWW-Authenticate header is when making an unauthenticated request (the three error codes provided add little to no value on top of the existing HTTP…

Actually, providing an HTML representation for 401 responses with "here is how to can get started to supply an Authorization header to access this resource" is a good step towards discoverability. 

> This means the header is defined solely as a potential future extension point for discovery, which brings me back to the first issue. The WWW-Authenticate header is not the right place to provide a…

Including identifiers (like media types, encoding names, or even auth schems) as part of the protocol gives some indirection to their specifications elsewhere (though not perfect, such as an IANA registry).

Subbu

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 19 Jan 2011 01:01:14 -0700

> Sent: Tuesday, January 18, 2011 11:37 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> > OAuth is an authorization protocol not an authentication protocol. With the
> exception of the client password credentials passed in the form-encoded
> body, the protocol is completely authentication agnostic for both client
> authentication and end-user login. Add to that the recent separation of the
> token authentication schemes, and you get a clean and well defined
> authorization model.
> >
> > A client using a token has to answer two questions: how to obtain
> authorization and how to use the provided authorization to access the
> protected resource. As currently specified, the header answers neither. In
> addition, for this to be a challenge response protocol, the client response
> must match the challenge which is not possible if the response can use
> different schemes based on the token type issued. That has proven very
> confusing to people on this list.
> 
> I agree about the separation, but a better fix is to name the protocols that
> the client can use for each step as part of this header. In any case, 401
> responses are required (a MUST in 2616) to have a WWW-Authenticate
> header with a scheme. Dropping the header is not a choice that the OAuth
> draft or can/should make. Leaving the scheme name choice to each
> implementation would be confusing to the community.

It isn't that confusing. The 401 response will include the WWW-Authenticate header of the scheme used with the token issued for that resource. Since clients never even look at the header today, they will not be confused by anything. Server developers might be, but it should be addressed by writing quality token type specifications with clear examples.
 
> > The only case a client is going to encounter the WWW-Authenticate header
> is when making an unauthenticated request (the three error codes provided
> add little to no value on top of the existing HTTP status codes). The only time
> that will happen is when the client is unfamiliar with the server. In such a
> case, the protocol as specified provides no further steps. The resource server
> is saying 'I support OAuth2' but implicitly saying 'and good luck figuring out
> what to do next'. For this to provide any actual interoperability at this level,
> the header must provide the supported profiles, endpoints, extensions,
> scope, etc. None of that is currently available.
> 
> Actually, providing an HTML representation for 401 responses with "here is
> how to can get started to supply an Authorization header to access this
> resource" is a good step towards discoverability.

I hope you are kidding... providing discovery in human-readable format helps the client how?

> > This means the header is defined solely as a potential future extension
> point for discovery, which brings me back to the first issue. The WWW-
> Authenticate header is not the right place to provide authorization server
> discovery information. I think our inability to fit 'realm' into our framework
> shows how the HTTP authentication headers are not meant for this.
> 
> Including identifiers (like media types, encoding names, or even auth
> schems) as part of the protocol gives some indirection to their specifications
> elsewhere (though not perfect, such as an IANA registry).

Can you give actual examples of how such responses help an OAuth *library* accomplish any level of interoperability?

EHL

---

From: Subbu Allamaraju <[email-masked]>
Date: Wed, 19 Jan 2011 00:15:37 -0800

> It isn't that confusing. The 401 response will include the WWW-Authenticate header of the scheme used with the token issued for that resource. Since clients never even look at the header today, the…

Why would the client developer/admin not look at the scheme? 

> I hope you are kidding... providing discovery in human-readable format helps the client how?

Nope. There is value in providing dev/debug-level discovery info. Saying nothing is worse.

> Can you give actual examples of how such responses help an OAuth *library* accomplish any level of interoperability?

By not having this header or header with some impl specific scheme? I'm not sure how to answer this question since I can't guess all the operating conditions of libraries, tools and intermediaries. If I were to write an OAuth-capable proxy, this header would tell it how what code to trigger in the case of auth failures (such as refreshing an access token). Plenty of examples exist for naming things via headers in all MIME-based protocols. I'm not seeing the value in making the OAuth over HTTP more opaque. In any case, 401 responses MUST accompany a WWW-Authenticate header.

Subbu

---

From: William Mills <[email-masked]>
Date: Wed, 19 Jan 2011 09:05:55 -0800

My initial implementation of a SASL mechanism is now published at https://github.com/sweetums/SASL-OAuth and it conforms to the discovery mechanism in the draft spec for the mechanism.

The code is pretty rough, and there's some major portability work to do as well as the fact that there's no automake and such.  Please feel free to create issues on github if you find things.

-bill

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 10:22 PM
To: William Mills; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme

EHL

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 19 Jan 2011 10:15:38 -0700

You're going to make me do all the work...

Where's the spec?

EHL

From: William Mills [mailto:[email-masked]]
Sent: Wednesday, January 19, 2011 9:06 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme

-bill

EHL

EHL

---

From: William Mills <[email-masked]>
Date: Wed, 19 Jan 2011 09:38:52 -0800

http://www.ietf.org/internet-drafts/draft-mills-kitten-sasl-oauth-00.txt

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Wednesday, January 19, 2011 9:16 AM
To: William Mills; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme

Where's the spec?

EHL

-bill

EHL

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 19 Jan 2011 10:45:44 -0700

Thanks.

Seems like this draft is based on an old version of the v2 specification. Stuff like signature and endpoint location is long gone...

EHL

From: William Mills [mailto:[email-masked]]
Sent: Wednesday, January 19, 2011 9:39 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme

Where's the spec?

EHL

-bill

EHL

EHL

---

From: William Mills <[email-masked]>
Date: Wed, 19 Jan 2011 09:50:51 -0800

Yes it's old, 1 week form expiring too.  The specs seem to be stabilizing now so it's worth updating.   Has there been any other discovery proposal yet?

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Wednesday, January 19, 2011 9:46 AM
To: William Mills; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme

Thanks.

EHL

Where's the spec?

EHL

-bill

EHL

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 19 Jan 2011 09:59:02 -0800

On Wed, Jan 19, 2011 at 9:50 AM, William Mills <[email-masked]> wrote:
> Yes it’s old, 1 week form expiring too.  The specs seem to be stabilizing
> now so it’s worth updating.   Has there been any other discovery proposal
> yet?

Nothing concrete AFAIK, but for SASL we also discussed using host-meta
style discovery. Somehow this approach seemed cleaner to me, but of
course it needs work (to define file location/format/content).

Marius

---

From: William Mills <[email-masked]>
Date: Thu, 20 Jan 2011 08:45:07 -0800

Yes, host-meta is definitely in play.  I do want the SASL profile to be able to specify discovery info in-band too though.  So the discovery returned in the SASL profile might be a host-meta indication or it might be the relevant contents if the SASL profile wants to override what might be normal for the domain.

-bill

> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Wednesday, January 19, 2011 9:59 AM
> To: William Mills
> Cc: Eran Hammer-Lahav; OAuth WG
> > Yes it's old, 1 week form expiring too.  The specs seem to be
> stabilizing
> > now so it's worth updating.   Has there been any other discovery
> proposal
> > yet?
>

---

From: <[email-masked]>
Date: Thu, 20 Jan 2011 18:39:24 +0100

My java code for implementing the new JSON Web Token draft-01
 http://self-issued.info/docs/draft-jones-json-web-token-01.html
is ready and commited to the openinfocard source code repository.

JUNIT tests are here:
 
https://code.google.com/p/openinfocard/source/browse/trunk/testsrc/org/x
mldap/json/WebTokenTest.java
The JUNIT test verify all examples from the draft-01.

The implementation is here:
 
https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmlda
p/json/WebToken.java

The code supports all algorithms and all size variants.
HS256, HS384, HS512 : HMAC with sha256, sha384, sha512
RS256, RS384, RS512 : RSA with  sha256, sha384, sha512
ES256, ES384, ES512 : ECDSA 256, 384, 521 (sic) with sha256, sha384,
sha512

Cheers
Axel

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Jan 2011 17:58:30 +0000

Very cool!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, January 20, 2011 9:39 AM
To: [email-masked]
Subject: [OAUTH-WG] JSON Web Token Java implementation

My java code for implementing the new JSON Web Token draft-01  http://self-issued.info/docs/draft-jones-json-web-token-01.html
is ready and commited to the openinfocard source code repository.

JUNIT tests are here:

 

The code supports all algorithms and all size variants.
HS256, HS384, HS512 : HMAC with sha256, sha384, sha512 RS256, RS384, RS512 : RSA with  sha256, sha384, sha512 ES256, ES384, ES512 : ECDSA 256, 384, 521 (sic) with sha256, sha384,
sha512

Cheers
Axel