Add wallet attestation to the SIOP response
Issue #1412
resolved
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
Comments (20)
-
-
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?
-
reporter
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/
-
reporter
App Attestations as potential mechanims: Establishing Your App’s Integrity | Apple Developer Documentation
-
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.
-
reporter
- changed status to resolved
Closing with PR #157 (cc @Torsten Lodderstedt )
-
reporter
- changed status to open
per Torsten's request
-
- changed title to Add wallet attestation to the SIOP response
-
I suggest to add attestation as basic feature to OpenID4VPs and reference it from SIOP.
-
-
assigned issue to
Torsten Lodderstedt
-
assigned issue to
-
I will create a PR that uses JARM for that purpose.
-
Has this issue been given a PR for resolution?
-
not yet - I have it on my list.
-
PR #377 resolves that issue
-
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?
-
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.
-
reporter
SIOP call Jan-05-2023 agree to address this issue by clarifying that JARM can be used for wallet attestations in SIOPv2 and OID4VP
-
I suggest to add implementation considerations for that purpose.
-
reporter
issue
#1887was a dupeWallet 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.
-
- changed status to resolved
Migrated to GitHub
- Log in to comment
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?