Those claims are asserted by the issuer of the assertion, which could be a trusted third party. Trust management happens on top of the draft. This could mean x5c, could also be a trust list with the issuer URLs. In the OID4VC High Assurance Profile, which utilizes this draft, we will facilitate both options. Am 21. Juli 2023, 18:25 +0200 schrieb Orie Steele <orie@transmute.industries>: > It would be excellent to see more information on "attested_security_context" > and "key_type" which appear in the example > https://datatracker.ietf.org/doc/html/draft-looker-oauth-attestation-based-client-auth-00#name-wallet-instance-attestation > > I gather from searching that this is relevant: > https://github.com/italia/eudi-wallet-it-docs/blob/722d50be9b296d1d28218eac50f8c9c3b10d8563/docs/en/wallet-solution.rst#L135 > > It seems a bit odd, to believe a client to make these kinds of assertions by > themselves... Has there been any discussion of x5c or cert chains for the cnf > key? > > OS > > > On Fri, Jul 21, 2023 at 12:25 AM Tobias Looker <tobias.looker@mattr.global> > > wrote: > > > Thanks for the feedback. Generally any OAuth client could make use of > > > this authentication method if they so wish, however the types of client > > > this draft has initially been designed for are ones that don’t typically > > > have good direct authentication options available today (e.g public > > > clients). > > > > > > Thanks, > > > <> > > > > > > Tobias Looker > > > MATTR > > > +64 273 780 461 > > > tobias.looker@mattr.global > > > <> > > > <> > > > <> > > > <> > > > > > > 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. > > > > > > From: Orie Steele <orie@transmute.industries> > > > Date: Friday, 21 July 2023 at 7:05 AM > > > To: Tobias Looker <tobias.looker@mattr.global> > > > Cc: oauth@ietf.org <oauth@ietf.org> > > > Subject: Re: [OAUTH-WG] OAuth 2.0 Attestation-Based Client Authentication > > > EXTERNAL EMAIL: This email originated outside of our organisation. Do not > > > click links or open attachments unless you recognise the sender and know > > > the content is safe. > > > > > > Really excited for this, I'm especially interested in how this might > > > apply to M2M flows, related to this part here: > > > https://datatracker.ietf.org/doc/html/rfc7521#section-4.2 > > > > > > It seems very targeted towards mobile / desktop apps, would it work for > > > servers / command line tools, etc? > > > > > > OS > > > > > > > > > On Thu, Jul 20, 2023 at 1:57 PM 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, > > > > <image001.png> > > > > > > > > Tobias Looker > > > > MATTR > > > > +64 273 780 461 > > > > tobias.looker@mattr.global > > > > > > > > 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 > > > > > > > > > -- > > > > > > ORIE STEELE > > > Chief Technology Officer > > > www.transmute.industries > > > -- > > ORIE STEELE > Chief Technology Officer > www.transmute.industries > > _______________________________________________ > 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
