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
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
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
>
-