George,
Thanks for the detailed responses. I have a few questions / comments inline.
Thanks,
Ned
From: George Fletcher <george.fletc...@capitalone.com>
Date: Friday, July 28, 2023 at 11:47 AM
To: "Smith, Ned" <ned.sm...@intel.com>, Thomas Hardjono <hardj...@mit.edu>,
"oauth@ietf.org" <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 both cases with the same flow. We might need an
initial step for the client to obtain a
[nms] We struggled with the lack of an “initial step” in OIDC / OAUTH examples.
This would be tremendously helpful.
nonce from the OpenID Provider before presenting the attestation so that the
attestation can contain the nonce
[nms] I agree a nonce would be useful. However, there are use cases where the
Attester is composed of multiple environments and some of those environments
are measured at different times (e.g., at boot time). Therefore, it isn’t
practical (usually) for a single nonce from the AS to be the sole form of
Evidence freshness.
allowing the OpenID provider to know this is a fresh attestation and bound into
the authorization process requested by the client.
[nms] I agree that binding the attestation Evidence to the process is
important. Likewise, binding Attestation Results to the process is also
important. Due to the use of “attestations” terminology, it is unclear to me
whether that implies Evidence, Attestation Results, or both.
Thanks,
George
--
[Image removed by sender. Capital One]
George Fletcher (he/him)
Executive Distinguished Engineer • Identity Architect
[Image removed by sender. address]8020 Towers Crescent Drive, Vienna, VA 22128
[Image removed by sender. mobile]616-498-8240
assistant:
genevieve.mor...@capitalone.com<mailto: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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
