I have concerns, similar to Orie's, about assertions. Like Orie, I would like to see something like this approved, but it must be secure. The following is the part of the draft that concerns me.
Therefore, the client generates a key (Client Instance Key) and (platform specific) attestations to prove its authenticity, integrity and security to the client backend (step 1) First - I assume this is a web client, is that correct? It is not stated anywhere I looked. So I have been following an effort in blink-dev to have the browser API include assertions of the sort I believe are of interest here. That is generated by the DOM. https://rupertbenwiser.github.io/Web-Environment-Integrity/ My concern is that there is a large amount of push back to seeing this approved. If approved it would allow what you ask. If not it is unclear to me how you would achieve the "(platform specific) attestations to prove its authenticity". If you have more detail on how this might work on android and iphone, I would like to hear it. In the mean-time i am working to get the above Web-Environment-Integrity/ change approved. If you would like to help make that possible let me know that you would put your name to the effort. ______________________________________________________________________________________________________ Of course, if this is a native client, we can use other methods that are available today to proof it. ..tom On Thu, Jul 20, 2023 at 11:57 AM Tobias Looker <tobias.looker= 40mattr.glo...@dmarc.ietf.org> wrote: > Hi All, > > > > Paul and I would like to draw attention to a new draft we have submitted > titled “OAuth 2.0 Attestation-Based Client Authentication” which will be > presented at the up and coming IETF 117 meeting during the Friday meeting > slot. This draft is related to the group of drafts on verifiable > credentials that will be presented during this meeting slot. Specifically > this draft is intended to address but not limited to eIDAS 2.0 usage of > OpenID4VCI which requires wallet applications to be strongly authenticated > via attestations. > > > > The current abstract of the draft is as follows: > > > > “This specification defines a new method of client authentication for > OAuth 2.0 [RFC6749] by extending the approach defined in [RFC7521]. This > new method enables client deployments that are traditionally viewed as > public clients to be able to authenticate with the authorization server > through an attestation based authentication scheme.” > > > > Link to the current editors copy => > https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/ > > > Link to the specification repository => > https://github.com/vcstuff/draft-looker-oauth-attestation-based-client-auth > > > > Thanks, > > [image: MATTR website] <https://mattr.global/> > > > > *Tobias Looker* > > MATTR > > +64 273 780 461 > tobias.looker@mattr.global <first.last@mattr.global> > > [image: MATTR website] <https://mattr.global/> > > [image: MATTR on LinkedIn] <https://www.linkedin.com/company/mattrglobal> > > [image: MATTR on Twitter] <https://twitter.com/mattrglobal> > > [image: MATTR on Github] <https://github.com/mattrglobal> > > > This communication, including any attachments, is confidential. If you are > not the intended recipient, you should not read it – please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
