On the subject of making the spec(s) less JWT specific, it was a foundational assumption and (I think) in the charter. However COSE wasn't around yet.
I suppose the more generic architecture doc could be altered to cover IoT cases, but it may be problematic for the other specs that are more specific. Another issue is I assume the COSE based tokens will have a different type (eg cpop) to differentiate between jwt and COSE web tokens (what are we calling them now?). As this generalization change could be seen as substantial, I would like to have the chairs and AD comment. Is this a good idea? Or is COSE better to write their own parallel arch draft? I'm happy to bend to the will of the group(s) on this. Phil > On Nov 19, 2015, at 01:17, Erik Wahlström neXus > <[email protected]> wrote: > > Hi, > > I have been reviewing draft-ietf-oauth-pop-architecture-05. In ACE WG we have > a draft that uses PoP tokens for IoT and the architectures defined here so my > review was done with that IoT perspective. I’m a bit late with the review and > some of the comments might already be mentioned by others. > > > > —————— > > 3.1. Preventing Access Token Re-Use by the Resource Server > > If a symmetric key is used it’s possible to re-use the key for a resource > server. The section talks about the importance of scopes, but I feel it > should also mention the importance for the resource server to verify the > audience (“aud”) claim in the token to disable missuse. > > —————— > > The draft in ACE WG > (https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00) relies heavily > on this work. The main reason for this is the way PoP tokens can establish > key material, with the help of the authorization server, on both the client > and resource server. PoP tokens is also a very good fit for constrained IoT > devices that can be offline and it’s also possible to use hardware key > storages to handle asymmetric pop keys. > > There could be a place for a new "Use Case" under section 3 that talks about > scenarios where PoP keys are a really good match for offline IoT devices. I > could help out ironing out a text for that with the help of the docs authors > if that’s of interest. > > ——— > > s/a bogus tokens/a bogus token > > —— > > In the document only references are made to JSON, JWT and JOSE. More exactly > in the following two sections: > > A number of the threats listed in Section 4 demand protection of the > access token content and a standardized solution, in form of a JSON- > based format, is available with the JWT [RFC7519]. > > > With the JSON Web Token (JWT) [RFC7519] a standardized format for > access tokens is available. The necessary elements to bind symmetric > or asymmetric keys to a JWT are described in > [I-D.ietf-oauth-proof-of-possession]. > > Constrained IoT devices uses other access token and messages formats > (according to our draft). It does not only use signed/encrypted JWT’s but > also COSE protected CBOR Web Tokens. See > https://tools.ietf.org/id/draft-wahlstroem-oauth-cbor-web-token-00.txt > > I totally agree that JWT is the correct examples to have in this document due > to the fact that they are RFC’s, they are well known and should be used in as > many places as possible, but it would be good to open up for other types of > message formats. For example like this: > > > A number of the threats listed in Section 4 demand protection of the > access token content and a standardized solution in form of, for example, > a JSON- > based format, is available with the JWT [RFC7519]. > > > —— > > For that > purpose the client will have to authenticate the resource server > before transmitting the access token. > > > I’m missing a description about how this is handled in an end-to-end security > scenario. > > ——— > > The resource server queries the authorization server for the > symmetric key. This is an approach envisioned by the token > introspection endpoint [I-D.ietf-oauth-introspection]. > > > Not a question for this draft maybe, but in what draft is the introspection > response claim defined? It’s not defined in > https://tools.ietf.org/html/rfc7662#section-2.2 and I don’t know in what > other draft it can be defined. > > —— > > In ACE WG the draft seitz-ace-oauth-authz have a profile for an access > request to make it work over CoAP. CoAP is the HTTP equivalent for > constrained devices, and it has limitations, for example it can’t send large > tokens in options (headers in "http-speak"). This means that the draft > defines a way to first send the PoP token to an new endpoint on the resource > server to establish a security context. Then the real request against the > resource server can be done once the security context is established. See > more details here > https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#section-5.2. > > An open question; should a flow like that be added to the architecture > section? That means a new section 7.5. > > —— > > Thanks for writing this. I think it’s very important work. > > / Erik > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
