On 04/10/18 03:47, Jim Schaad wrote:
The OAuth group discovered a problem with some the names of our new OAuth
fields that was caused by the fact that they have an ID that is someplace
between the IESG and the RFC Editor which introduced the concept of using a
JWT to as the transport for an OAuth request. This allows for doing
end-to-end security on the OAuth request in the event it needs to be
forwarded to another authorizer. Due to the design decision that they made,
this was done by included all of the OAuth request fields as JWT claims thus
combining the two namespaces. Based on this we now need to make a decision
on what to do with our COSE versions of this. From my point of view we have
two different options:
1. Ignore the problem and hope it goes away.
2. Deal with the problem by combining the current CWT registry with the
OAuth registry that is going to be created.
Why option 1 might be acceptable:
A. The reason that they are doing this is because they want to get an E2E
solution for requests. We have this already to some degree with the OSCORE
profile of OAuth and could easily go the rest of the way by creating a COSE
profile which allowed for full COSE rather than the restricted version of
OSCORE. There may be some unknown benefits to using a JWT for this
purpose, but I would then want to ask two questions: Is this really
something that is useful and important? If is really that important or
useful, why is it not part of the base OAuth protocol?
B. If a CWT version is this is really needed, perhaps we can get a different
design to be used. Specifically, create two new CWT claims: "oauth_req",
"oauth_resp" and then place the OAuth parameters in those fields and not
make them CWT claims. I am sure that there would be complaints about this,
but much as COSE fixed problems that it saw as being wrong, the WG could do
the same thing.
Jim
I'm not sure if there really is a problem here. If an AS forwards a
{C/J}WT to another AS, this would clearly not be an access token,
meaning the claims can be interpreted accordingly. If there is room for
confusion OAuth should define a token type such as e.g. "request_token"
and make that a mandatory claim in the token or parameter of the request.
Therefore I would lean towards option 1.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
