Re: [OAUTH-WG] Basic signature support in the core specification

[Torsten Lodderstedt <[e-mail]>]

  Am 27.09.2010 22:53, schrieb Dick Hardt:
> On 2010-09-27, at 11:25 AM, Torsten Lodderstedt wrote:
>
>> Am 27.09.2010 19:11, schrieb Anthony Nadalin:
>>> What is needed is needed is the security considerations section complete, I don't think that the signature specification has to be in the core to be complete, there are previsions to use SSL, if one needs to go beyond this then a reference to the signature specification would be in the security considerations section. The separation allows for an OAuth independent solution that would/could cover message and token encryption and signing. If signature is going to be an extension point
>> I don't understand why signing tokens and signing message shall be solved with the same solution.
> They don't have to use the same solution, but you have the same issues (discovery, key management) in both cases, so why not solve them the same way?

This depends on the objective. Message signing and prove of possession 
can be achieved using AS generated short-living token secrets. I don't 
see a need for discovery here. I agree for all other use cases.

>> In my opinion, tokens are opaque to any client and are just passed through as an uninterpreted string from authorization server (AS) to the resource server (RS) via the client. So the OAuth spec does not necessarily have to standardize their format (incl. signatures) in order to facilitate protocol interoperability. AS and RS just have to use the same format. Since both have a thight relationship that should not be a problem. If one like it can use an existing formats like SAML assertions or SWT.
> If the AS and RS are tightly bound, then the token can be opaque. If there is one to many or many to many relationships, then you need a standard token, and for scale, you want to sign the token.

Even for the such relationships between AS and RS, the token can be 
opaque wrt the client.

Please note: I didn't argue against having a standardized token format 
or signing self-contained tokens. But in contrast to message signing 
between client and RS, this is in my opinion not required for achieving 
a reasonable security level and interop in the first step. If the WG 
wants to achieve interop between independent AS and RS, this should 
explicitely stated somewhere and would have significant impact all over 
the spec. So far we don't even have a way to identify RSs in a portable 
way. WG consensous was to let this aspect be deployment specific.

regards,
Torsten.

>> That's completely different from message signing. Here all parties are involved. So any client accessing a pair of AS and RS has to know how to sign a message in order to prove legitimate token ownership and/or protect the message from modifications.
> See point above.
>
> -- Dick
>