Add wallet attestation to the SIOP response

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1412

Original Reporter: KristinaYasuda

I think we should allow SIOP to communicate “the identity of SIOP/AS“ in the ID Token. We could define an “attestn” (attestation) claim that includes identifier of the SIOP provider/AS, and a signature by that provider for integrity protection.

some initial thoughts inspired by a conversation in this issue: https://bitbucket.org/openid/connect/issues/1400/issuer-handling-in-siop#comment-61728537

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

I think what we need is a second signature with the SIOP provider's key over the ID token or a signature tied to the ID token and transaction. Could we put that into the JWT header?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: StDurand

I’m assuming that this attestation you refer to is an attestation delivered to the wallet as a product or service (not a specific instance of these), and such attestation is given in recognition of purpose suitability by a relevant authority in the trust framework.

Then I expect that the trust links to be like: SIOP provider attestation → SIOP key proof → ID Token

If we have the SIOP provider attestation included inside the ID Token, it reverses the first arrow and in my opinion, the reversed arrow proves nothing of relevance.

If we have the attestation used to directly sign the ID Token, my concern is that we decouple the signing of the ID Token by the SOP from its legitimacy to do so. Somehow we still have the two signatures, but it feels weaker in term of security. For one, the attestation-related signing material would need to be deployed on every wallet instances so it just needs breaching of one instance to get it… and then use it in a wider 'operation'.

I’m not entirely familiar with the work on OIDC Federation, but couldn’t it be a better candidate to convey the chain of trust related to the SIOP key proof?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

SIOP 2022-Feb-10 call.

• Can we add two signatures to the ID Token? IETF RATS is working on EAT (Entity Attestation Token) that might be useful: https://datatracker.ietf.org/doc/draft-ietf-rats-eat/

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

App Attestations as potential mechanims: Establishing Your App’s Integrity | Apple Developer Documentation

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt_yes_com

The way I read App attestation it is intended to be used between an app and its server. I would therefore assume we need to built on top of an architecture where the server/backend of an app can use that mechanism to establish trust (internally) in its frontend but trust between RP and OP relies on client authentication and/or server-created signatures. I created a PR with a proposal (PR #152) for OP attestation.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

Closing with PR #157 (cc @{557058:cf344cf5-3085-4fd6-abb3-eaa88b0f0ab9} )

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

per Torsten's request

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

I suggest to add attestation as basic feature to OpenID4VPs and reference it from SIOP.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

I will create a PR that uses JARM for that purpose.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

Has this issue been given a PR for resolution?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

not yet - I have it on my list.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

PR #377 resolves that issue

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

Great

What do you think about the definition of “wallet attestation”?

We assume that PR 377 offers a kind of attestation, do we have more than a single attestation type in the wallet multiverse?

I would like to start over with the definition of wallet attestation, how many attestation type and mechanisms we may have?

I agree on torsten's architectural view that defines the components of app frontend and app backend (or wallet provider, anyway, that server). The server should be a trusted actor.

But, what we May do if we dont use this architecture with app+server? May we assume this?

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

PR #377 explicitly states that JARM can be used with OpenID4VPs. A wallet can use the signed response to authenticate to the verifier, which is the basis for attestation. I would assume the authenticated wallet or wallet provider identity is then checked against trusted registries or certificates to establish trust.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

SIOP call Jan-05-2023 agree to address this issue by clarifying that JARM can be used for wallet attestations in SIOPv2 and OID4VP

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

I suggest to add implementation considerations for that purpose.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

issue #1887 was a dupe

Wallet attestation is expressed as a VP. Verifier requests presentation of a VP of a type wallet authentication that is sent alongside ID Token. Question is whether/how to align with VCI wallet attestation approach.

‌