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