So, you mean… If a frontend client want to use * sender-constrained code, bearer access token and sender-constrained refresh token, use DynReg. * sender-constrained code, sender-constrained access token and sender-constrained refresh token, use DynReg + DPoP. * bearer code, sender-constrained access token and sender-constrained refresh token, use DPoP only. * bearer code, bearer access token and bearer refresh token, use neither.
is my understanding correct?? > 2020/06/07 20:49、Neil Madden <[email protected]>のメール: > > There are multiple issues with using dynamic client registration for this. If > a user uninstalls and later reinstalls an app then they can end up with > multiple registrations for the same client, which makes it harder for them to > manage access. Additionally, client registrations typically don’t expire so > the AS doesn’t know when it can remove unused clients. > > Besides, this ship already sailed with mTLS cert-bound refresh tokens. > > Neil > >> On 7 Jun 2020, at 12:34, Nov Matake <[email protected]> wrote: >> >> Confidential clients can also use DPoP. >> >>> 2020/06/07 20:25、Torsten Lodderstedt <[email protected] >>> <mailto:[email protected]>>のメール: >>> >>> If the client would register for every transaction. >>> >>> And don’t forget, DPoP also supports sender constrained access to resource >>> servers, which dyn registration does not. >>> >>>> Am 07.06.2020 um 13:04 schrieb Nov Matake <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>> Since each client instance has at least one key, those are same level of >>>> state management. >>>> >>>>> 2020/06/07 16:24、Torsten Lodderstedt <[email protected] >>>>> <mailto:[email protected]>>のメール: >>>>> >>>>> There are similarities in this particular use case but I would argue DPoP >>>>> is more light weight than dynamic client registration, less state >>>>> management in particular. >>>>> >>>>>> Am 07.06.2020 um 05:41 schrieb Nov Matake <[email protected] >>>>>> <mailto:[email protected]>>: >>>>>> >>>>>> DPoP-bound refresh token seems feature duplication with dynamic client >>>>>> registration. >>>>>> >>>>>>> 2020/06/07 7:57、Francis Pouatcha <[email protected] >>>>>>> <mailto:[email protected]>>のメール: >>>>>>> >>>>>>> >>>>>>> > Am 05.06.2020 um 22:17 schrieb George Fletcher <gffletch=40aol.com >>>>>>> > <http://40aol.com/>@dmarc..ietf.org <http://ietf.org/>>: >>>>>>> > >>>>>>> > Secondly, I do think we need a way to allow for the refresh_token to >>>>>>> > be bound while leaving the access_tokens as bearer tokens. This adds >>>>>>> > useful security without impacting existing RS deployments. >>>>>>> >>>>>>> +1 that’s a very useful >>>>>>> feature_______________________________________________ >>>>>>> AFAIK a refresh_token is always bound. What am I missing here? >>>>>>> -- >>>>>>> Francis Pouatcha >>>>>>> Co-Founder and Technical Lead at adorys >>>>>>> https://adorsys-platform.de/solutions/ >>>>>>> <https://adorsys-platform.de/solutions/>_______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>> >>>> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
