Re: [OAUTH-WG] Adhoc meeting at IETF 117 for anyone interested in attested Open-ID/Connect

[Smith, Ned]

Thomas Hardjono and I are hosting an ad-hoc meeting to discuss and gauge 
interest in attested Open-ID/Connect.
We will meet in the hotel lobby on Wednesday @ 1:00 PM.
There is a -00 draft here: draft-sh-rats-oidcatt-00 - Attestation in 
OpenID-Connect 
(ietf.org) for context.

Thanks,
Ned / Thomas
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Feed back on draft-sh-rats-oidc at-00

[Smith, Ned]

George,
Thanks for the detailed responses. I have a few questions / comments inline.
Thanks,
Ned

From: George Fletcher 
Date: Friday, July 28, 2023 at 11:47 AM
To: "Smith, Ned" , Thomas Hardjono , 
"oauth@ietf.org" 
Subject: Feed back on draft-sh-rats-oidc at-00

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
 
^^
[nms] I’m still confused about the OAUTH WG use of “attestations”. The noun 
form of attestation doesn’t seem to be defined anywhere. The RATS Architecture 
carefully avoided defining “attestation” opting instead to define roles and 
conceptual messages. draft-tschofenig-oauth-attested-dclient-reg seemed to do a 
good job of mapping terminology to RFC9334. However, based on clarification 
from the session III OAUTH meeting in 117, it seems the definition of 
attestations might be “attributes that have provenance metadata”. This 
definition differs from what is intended in draft-sh-rats-oidcattest. Maybe it 
makes sense to try to capture some definitions for what seems to be tribal 
knowledge of the OAUTH WG?

Provider playing the role of a RRP).

[nms] The draft-tschofenig-oauth-attested-dclient-reg seems to take this 
approach also. I’m confused by that because the entity taking the risk 
associated with interacting with the client is the RS (OIDC RP). If the AS is 
providing a blanket policy for the Internet that all agree to, then I can see 
this approach (AS as RRP) making sense. But not sure such a broad policy would 
be meaningful for anyone.

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.

[nms] Thomas and I have a busy sequence diagram that isn’t easily included in a 
draft. Having mermaid would help. Nevertheless, we did include most of the 
sequences broken up in the various sections. However, they don’t seem to be 
rendering properly. The Editor’s Copy at nedmsmith/draft-sh-rats-oidc-attest: 
Internet draft describing integration of attestation flows with openID-connect 
(github.com)<https://github.com/nedmsmith/draft-sh-rats-oidc-attest> seems to 
render properly.

In my view, it’s more likely that the OpenID Provider will be the entity 
desiring an attestation about the client

[nms] By “attestation” I assume you mean Evidence?

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

[nms] RFC9334 tries to point out that an Attester shouldn’t attempt to 
self-attest as that implies the Attester can lie about its state. Rather, an 
Attesting Environment (which is trusted) should collect Evidence about the 
“client”.

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 bot

Re: [OAUTH-WG] Adhoc meeting at IETF 117 for anyone interested in attested Open-ID/Connect and Oauth2

[Smith, Ned]

Folks,
We had a side-bar meeting at the IETF117 last week in San Francisco, regarding 
the possible use of OpenID-Connect/OAuth2.0 as a mechanism to deliver 
RATS-based device-attestation.

The meeting was attended by about 15 people, mostly from the Identity community 
(folks who regularly attend OAuth2.0, OIF and IWW).

From the start of the discussion, it was clear that there was some terminology 
mismatch between the various folks & communities.

For example, in the OAuth2.0 language the word "Client" is typically used to 
mean the service which is being driven by the user (e.g., to authorize access 
to a Resource Server (RS), which is typically also a RESTful web-based service).

However, in RATS and TCG language, the "Client" often means the hardware device 
(in the possession of a user) which will generate evidence regarding the 
composition (hardware, firmware, software) of the device.

Some folks also mentioned interesting use-cases that the RATS community perhaps 
have not previously considered. For example, prior to connecting to the RS it 
is possible that the OAuth2.0 Client (e.g., hosted by a provider) may seek 
device-attestations from RS machine itself (and vice versa).

All in all, we believe that a productive next step would be a discussion on the 
RATS mail-list regarding common Terminology, something that is meaningful to 
the RATS community as well as the broader IETF community.

There are 3 I-Ds that are in early stages that seem to be describing aspects of 
a comprehensive approach to attestation for identity infrastructures:
 
https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/,
 https://datatracker.ietf.org/doc/draft-tschofenig-oauth-attested-dclient-reg/,
 https://datatracker.ietf.org/doc/draft-sh-rats-oidcatt/
Referring to these drafts for context (and possible disagreement) may help with 
the conversation.

I’m cross posting to several working groups, but the discussion thread will be 
exclusive to the RATS WG (r...@ietf.org).

Best
Ned & Thomas

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth