Re: [Ace] JWT + OAuth Request
> -Original Message- > From: Michael Richardson > Sent: Thursday, October 4, 2018 6:45 AM > To: Jim Schaad > Cc: ace@ietf.org > Subject: Re: [Ace] JWT + OAuth Request > > > 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 > > Took a moment to realize that ID = Internet Draft, rather than being a > reference a hash key id :-) (Which document is this?) This is JWT Secured Authorization Request (JAR) https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ Jim > > > Why option 1 might be acceptable: > > ... > > > 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. > > I prefer this solution, but I feel unsufficiently informed about how the above ID > might come back to bite us. > > (I can live with combining registries) > > -- > Michael Richardson , Sandelman Software Works - > = IPv6 IoT consulting =- > > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] JWT + OAuth Request
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 Took a moment to realize that ID = Internet Draft, rather than being a reference a hash key id :-) (Which document is this?) > Why option 1 might be acceptable: > 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. I prefer this solution, but I feel unsufficiently informed about how the above ID might come back to bite us. (I can live with combining registries) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] JWT + OAuth Request
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
