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? > > 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. > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
