Thanks for the links I will be getting right on it.
Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: OAuth <oauth-boun...@ietf.org> on behalf of oauth-requ...@ietf.org
<oauth-requ...@ietf.org>
Sent: Friday, July 28, 2023 3:00:03 PM
To: oauth@ietf.org <oauth@ietf.org>
Subject: OAuth Digest, Vol 177, Issue 24
Send OAuth mailing list submissions to
oauth@ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
oauth-requ...@ietf.org
You can reach the person managing the list at
oauth-ow...@ietf.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."
Today's Topics:
1. Re: OAuth 2.0 Attestation-Based Client Authentication
(Paul Bastian)
2. Feed back on draft-sh-rats-oidc at-00 (George Fletcher)
----------------------------------------------------------------------
Message: 1
Date: Fri, 28 Jul 2023 14:57:37 +0000 (+00:00)
From: Paul Bastian <paul.bast...@posteo.de>
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Attestation-Based Client
Authentication
Message-ID: <b1cfd321-7998-4fef-ae43-e42d5e365...@posteo.de>
Content-Type: text/plain; charset="utf-8"
Hello Tom,
Here is a link to the slide deck from IIW:
https://www.linkedin.com/posts/paul-bastian-1970b1195_slides-on-wallet-security-concepts-activity-7056179875635724289-pDXM?utm_source=share&utm_medium=member_android
Some things have evolved from there and this IETF draft is one of them.
I am not convinced that we should point out in the specification which specific
technologies today map well or not as these things tend to change over time,
but if that's fundamental to you, I ask you to please open an issue on our
GitHub page to track this.
Best regards, Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://mailarchive.ietf.org/arch/browse/oauth/attachments/20230728/148306c2/attachment.htm>
------------------------------
Message: 2
Date: Fri, 28 Jul 2023 08:16:30 -0700
From: George Fletcher <george.fletc...@capitalone.com>
To: "Smith, Ned" <ned.sm...@intel.com>, "hardj...@mit.edu"
<hardj...@mit.edu>, oauth@ietf.org
Subject: [OAUTH-WG] Feed back on draft-sh-rats-oidc at-00
Message-ID:
<CAJnLd9+FRG7DfLK4xrFfVqKwrL0Bf5Y=2rs4nsx_zmnt9qk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ned/Thomas,
Thanks so much for the conversation at IETF on the potential value of
combining the attestation work with OpenID Connect and OAuth. Given the
spec references a lot of OpenID Connect artifacts, I?ve used OpenID Connect
points in this response. However, from an IETF perspective, this would be
connected to OAuth and the Authorization Server. It might be useful to map
the work to OAuth directly and then let OpenID Connect (which is built on
top of OAuth) to ?inherit? the capability.
As promised, here is some feedback on the presented draft?
Section 2.1
* The userinfo endpoint is an API specified by the OpenID Connect protocol.
It?s usually part of the OpenID Provider. Regardless it?s not a
useragent/browser.
Section 3.1
* userinfo (see previous comment)
* End user (EU/Alice) is not an application. In OAuth the end user is
called the Resource Owner. The application is called the ?client?. So the
Resource Owner uses the client to access the RO?s resources.
* Relying Party - generally in OAuth/OpenID Connect the relying party is
not looking for attestations. It?s looking for an authorization token to be
presented by a client. In the case of attestations? it would be the OpenID
Provider that would be interested in the attestations (in this context it
may be possible to consider the OpenID Provider playing the role of a RRP).
Section 3.2.1
* this isn?t really how the OpenID connect protocol works. In a general
mobile app flow, the mobile app (aka the client) will open a browser to the
OpenID Provider?s /authorization endpoint which starts the
authentication/consent/authorization flow. Once the user has authenticated,
the OpenID Provider provides a ?code? back to the native application which
then exchanges that ?code? for the ?id-token and access-token? at the
/token endpoint of the OpenID Provider
Beyond this part of the spec I got confused on how the protocol is supposed
to work and who the core agents are in the flow. A diagram would be really
helpful showing the core steps.
In my view, it?s more likely that the OpenID Provider will be the entity
desiring an attestation about the client making the request. This could be
just an attestation about the client software, or could also include an
attestation about general characteristics of the device (e.g. is it jail
broken or not).
There are two main use cases?
1. The client is a mobile app in which case it may be able to obtain an
attestation before starting the authorization flow
2. The client is a web service (or relying party) and the OpenID Provider
wants some attestation about the software and environment in which that
client is running.
I suspect we can address both cases with the same flow. We might need an
initial step for the client to obtain a nonce from the OpenID Provider
before presenting the attestation so that the attestation can contain the
nonce allowing the OpenID provider to know this is a fresh attestation and
bound into the authorization process requested by the client.
Thanks,
George
--
[image: Capital One]
George Fletcher (he/him)
Executive Distinguished Engineer ? Identity Architect
[image: address]8020 Towers Crescent Drive, Vienna, VA 22128
[image: mobile]616-498-8240
assistant: [image: email] genevieve.mor...@capitalone.com
______________________________________________________________________
The information contained in this e-mail is confidential and/or proprietary to
Capital One and/or its affiliates and may only be used solely in performance of
work or services for Capital One. The information transmitted herewith is
intended only for use by the individual or entity to which it is addressed. If
the reader of this message is not the intended recipient, you are hereby
notified that any review, retransmission, dissemination, distribution, copying
or other use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error, please
contact the sender and delete the material from your computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://mailarchive.ietf.org/arch/browse/oauth/attachments/20230728/05512888/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------------------------------
End of OAuth Digest, Vol 177, Issue 24
**************************************
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
