[Openid-specs-ab] Comment on Messages

[John Bradley]

In a number of cases I expect that the OP will generate a JWT as the access token.

MAC tokens are mostly about being able to save the access token as a cookie.  I don't know that they add much.

I am OK with leaving it open to extension.  Though I a proper proof key mechanism for JWT is probably the way to go..

John
On 2011-09-06, at 3:04 PM, Andreas Åkre Solberg wrote:

> 
> On 3. sep.2011, at 06:34, Nat Sakimura wrote:
> 
>> While I sympathise with the need for flexibility, for the interoperability, profiling narrowly would be a good thing. 
> 
> Interoperability is super important, but it does not need to be in conflict with interoperability.
> 
> I'm in favor of spec-ing things like this:
> 
> Both Provider and RP MUST support Bearer Tokens. Both MAY support additional typen_types. A Provider MUST never issue other token types than "Bearer", unless the Provider has knowledge of which token_types the RP supports (using out of band negotiation, in example metadata).
> 
>> As to the criticism [1], I would not actually care. It is just the matter of using signed and possibly encrypted JWT as access_token if you wanted more security.
> 
> What do you mean? Do you mean that the RP will create the JWT, or that the bearer token received by the RP is a JWT generated by the OP.
> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110906/be0f255b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110906/be0f255b/attachment.p7s>