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

[George Fletcher <[e-mail]>]

Hi Ned,

I'm not sure how best to thread any responses...

Regarding terminology and definitions: I agree that this should be done and
be added to whatever document(s) are adopted by the working group. In
general, I suspect that within the OAuth working group "attestation" is a
general term describing a set of attributes that is signed by an entity the
receiver trusts that gives greater confidence that the client is an
application that the receiver is willing to work with.

>From a layering perspective, while not providing full confidence, I believe
most OAuth/OpenID Connect implementations are looking for statements
about the application and the device (e.g. jailbroken or not). The
motivation behind the "draft-looker-oauth-attestation-based-client-auth-00"
draft is a way for wallets (clients running on a mobile phone) to prove
their "authenticity" to an issuer so that the issuer will issue a
credential into the wallet. In this use case the issuer is acting kind of
like an AS and the wallet approximates an RP. When the wallet wants to
present claims to a verifier then the wallet takes on the role of the AS
and the verifier takes on the role of the RP. There is debate within the
OAuth working group as to whether "attestations" are needed between the
wallet and the verifier.

[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”.

>From a practical implementation perspective, the expectation is that the
attributes about the client and device come from the OS platform and are
not self-asserted. In Tobias' draft, the client backend is just there to
have a persistent set of signing credentials over the attributes obtained
from the OS platform.

However, this is an important point in any of this work as it's critical
for the receiver of the signed attributes to be able to trust them and that
they are misrepresented.


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

This gets to the completeness of the solution and how much of that is
required for the purpose of increasing trust in the client. I suspect that
within the OAuth working group the focus is on OS platform "attested"
attributes. This includes who wrote the application. Other statements about
the boot structure of the device and all its layers may be deemed less
critical. Another discussion we should have on the list.


Hopefully others will join in as it looks like the
draft-looker-oauth-attestation-based-client-auth-00 will be accepted by the
working group.

Thanks,
George

On Fri, Jul 28, 2023 at 11:30 PM Smith, Ned <[e-mail]> wrote:

> George,
>
> Thanks for the detailed responses. I have a few questions / comments
> inline.
>
> Thanks,
>
> Ned
>
>
>
> *From: *George Fletcher <[e-mail]>
> *Date: *Friday, July 28, 2023 at 11:47 AM
> *To: *"Smith, Ned" <[e-mail]>, Thomas Hardjono <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *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://urldefense.com/v3/__https://github.com/nedmsmith/draft-sh-rats-oidc-attest__;!!FrPt2g6CO4Wadw!Ivo-PfQMUiV7KrRWdYx0w9hDB5BCuf1xl7JV-pMjNCbqUzSAv82O3jUI5xBhqQXdBWl4RlzAEEAVvagc_ev933Piig$>
> 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: Image removed by sender. Capital One]
>
> *George Fletcher (he/him)*
>
> Executive Distinguished Engineer • Identity Architect
> [image: Image removed by sender. address]8020 Towers Crescent Drive,
> Vienna, VA 22128
> [image: Image removed by sender. mobile]616-498-8240
>
> assistant: [image: Image removed by sender. email]
> [e-mail]
> ------------------------------
>
>
>
>
> 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.
>
>
>
>

______________________________________________________________________



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.