Add wallet attestation to the SIOP response #6
Comments
Imported from AB/Connect bitbucket - Original Commenter: tlodderstedtI 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? |
Imported from AB/Connect bitbucket - Original Commenter: StDurandI’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? |
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasudaSIOP 2022-Feb-10 call.
|
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasudaApp Attestations as potential mechanims: Establishing Your App’s Integrity | Apple Developer Documentation |
Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt_yes_comThe 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. |
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasudaClosing with PR #157 (cc @{557058:cf344cf5-3085-4fd6-abb3-eaa88b0f0ab9} ) |
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasudaper Torsten's request |
Imported from AB/Connect bitbucket - Original Commenter: tlodderstedtI suggest to add attestation as basic feature to OpenID4VPs and reference it from SIOP. |
Imported from AB/Connect bitbucket - Original Commenter: tlodderstedtI will create a PR that uses JARM for that purpose. |
Imported from AB/Connect bitbucket - Original Commenter: peppelinuxHas this issue been given a PR for resolution? |
Imported from AB/Connect bitbucket - Original Commenter: tlodderstedtnot yet - I have it on my list. |
Imported from AB/Connect bitbucket - Original Commenter: tlodderstedtPR #377 resolves that issue |
Imported from AB/Connect bitbucket - Original Commenter: peppelinuxGreat 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? |
Imported from AB/Connect bitbucket - Original Commenter: tlodderstedtPR #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. |
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasudaSIOP call Jan-05-2023 agree to address this issue by clarifying that JARM can be used for wallet attestations in SIOPv2 and OID4VP |
Imported from AB/Connect bitbucket - Original Commenter: tlodderstedtI suggest to add implementation considerations for that purpose. |
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasudaissue #1887 was a dupe
|
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
The text was updated successfully, but these errors were encountered: