Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30

he name "The OAuth 2.0 Authorization Framework: JWT > > > > > Secured Authorization Request (JAR)" suggests, is a framework and > > > not > > > > > a house itself. One such example is FAPI [1] which was formally > > > > > verified [2]. > > > > > > > > "It's possible to use this draft security" I don't think should be > enough anymore. Rather it should be impossible to use insecurely. > > > > > > > > Mike> The draft describes how to use the mechanism securely. Yes, if > > Mike> portions of the draft (and those it depends upon) are not > > Mike> followed, insecure usage can result. That's true of any > > Mike> security draft. If there are additional specific requirements > > Mike> and/or recommendations needed, we'd be glad to add them. If so, > > Mike> please identify them. (Indeed, we're already doing so in > > Mike> response to your existing specific feedback.) > > > > > > > > Mike> As for past JWT problems, the JWT BCP [RFC 8725] was written at > the request of the IESG to identify and mitigate them - especially in light > of JWTs being used for additional use cases, such as STIR secured telephony > and securing first-responder services. If you believe that additional > generic JWT issues should be discussed and addressed, we could always > revise this BCP. But doing so is beyond the scope of this RFC. > > > > > > > > > [1] > > > > > https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md > > > > > [2] https://arxiv.org/abs/1901.11520 > > > > > > > > > > > > > > > > > Obviously this draft has had a long and tortured history with > > > > > > multiple reviews, and what I'm suggesting needs to happen is a > > > > lot > > > > > > of work. But it's essential in any security protocol to do this > > > > > > analysis and be clear about what is, and what is not, protected by > the protocol. > > > > > > > > > > OAuth JAR is nothing but just another binding to OAuth 2.0. Where > > > > > RFC6749 binds it to form encoding, it provides two additional bindings: > > > > > 1) binding to JWT, and > > > > > 2) binding to the pushed authorization request that is referenced > by a URI. > > > > > It is this simple. As such, it would also inherit some of the > > > > > shortcomings in RFC6749. However, it is not this document to address > > > > > them. It should be done by other documents so that the result can be > > > > > encoded using the mechanisms provided in this document. > > > > > > > > This is not a simple matter. JWT has a long and twisted history with > some pervasive errors in common libraries, and is a fairly large standard. > OAuth 2.0 is also large. Ensuring that the mapping has the right properties > is going to be a mess. If the encoding does not respect the semantics we > have a serious security issue. If implementors assume the encoding provides > properties it does not, we again have a security issue. > > > > > > > > Mike> See my previous comments on past JWT implementation errors and the > writing of the JWT BCP [RFC 8725] to address these. > > > > > > > > > It is quite surprising that this fact is not getting appreciated and > > > > > is taking such a long time to complete. > > > > > Maybe I should delete all the explanation text and leave it with > > > just > > > > > the core text. Explanation and justification text for defining > > > > > additional bindings probably are just distractions now as it is now > > > > > appreciated and used all over the world unlike when the project was > > > > > started. > > > > > > > > Mike> I would propose that we make only necessary changes to the draft > at this point. Let's finish this long-overdue specification! > > > > > > > > > > > > > > > > > > > > > Sincerely, > > > > > > Watson Ladd > > > > > > > > > > > > > > > > Thanks again for your detailed comments. > > > > > > > > > > Best wishes, > > > > > > > > > > -- > > > > > Nat Sakimura > > > > > NAT.Consulting LLC > > > > > > > > Mike> I now plan to create edits incorporating the proposed resolutions > above for review. > > > > > > > >Best wishes, > > > >-- Mike > > > > > > > > -- > > > > Astra mortemque praestare gradatim > > > > -- > Astra mortemque praestare gradatim > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Regards, *Deepak Tiwari|* Software Engineer Intigate Technologies Pvt. Ltd. | www.intigate.co.in Ist Floor, A-119 Sector-63 Noida (U.P.) 201301 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question

trings (entitlement names, >>> IDs, or links), an array of the "entitlements" objects from the SCIM User >>> schema (pages 65-66 of RFC 7643), or something else? >>> >>> Sincerely, >>> >>> Logan Widick >>> ___ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.* > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Regards, *Deepak Tiwari|* Software Engineer Intigate Technologies Pvt. Ltd. | www.intigate.co.in Ist Floor, A-119 Sector-63 Noida (U.P.) 201301 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] (no subject)

Remove my email On Thu, Sep 10, 2020 at 5:58 AM Tricia Dalton wrote: > 18b47345e3e8895f3662160c8819768222595852 > Remove my email > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -