openid / openid4vc_sectrust Goto Github PK

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

Original Reporter: danielfett

(Re “Cryptographic Holder Binding”)

Giuseppe De Marco

2023-03-06

An evil RP may receive a presentation of a VC with a signed nonce and re-present the same VC reusing the signed nonce to another RP (may we say nonce-reply?)

I’ve assumed that the presentation response should be signed with the private key linked to the public one binded in the VC.

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

Original Reporter: danielfett

Giuseppe De Marco

2023-03-06

this may introduce the concept of linked credentials, where a VC is not secure without another, that has the holder binding or is verifiable with a crypto method. The linked VC are linked with a claim

the security of the solutions must impose that the claim used for linking is uniquely assigned to the subject of the VCs. If I link two VC with my given name this is not secure at all, differently if I use a tax payer identification number or an eIDAS personal unique id

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

Original Reporter: danielfett

Re Trust Chain from Verifier to Issuer, end of first paragraph.

Kristina Yasuda

2023-02-28

The Verifier receives a presentation that is cryptographically tied to a credential that itself... this seems to assume cryptographic holder binding. is that true..?

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

Original Reporter: danielfett

By Kristina:

I am still finding the right words, but sections about Holder Binding in the Trust Model section were lengthy and felt like sitting inbetween the reader and the security and privacy requirements sections…

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

Original Reporter: danielfett

By Giuseppe: https://bitbucket.org/openid/connect/pull-requests/468#comment-375226671

Probably we could say something more on the meaning of the trust model.

I assume that a trust model defines the mechanisms thanks to which compliant entities MUST be authenticated to a regulatory framework, federation or trust infrastructure, if you prefer.

the trust model also defines the mechanisms by which VCs, their issuers and their holders MUST be validated and verified.

the trust model should answer the question "How can I trust this RP, or this VC, or this VCI?"

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

Original Reporter: danielfett

By Kristina:

term trust framework should be defined.

for example, the examples in the following sentenceThe Verifier decides, based on policy, regulation, conformity assessment, and/or contracts, to trust a certain Issuer... are paraphrased as a “trust framework“. while other occurrences say By convention, specification or trust framework

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

Original Reporter: danielfett

Re “The root of trust from the perspective of a Verifier is the Credential Issuer”

Giuseppe De Marco

2023-03-06

it may be the Authority that regulates a particular trust framework, where all the participant adehere

in a multilateral federation we may not assume that all the RP should known all the VCI, with direct trust relationship. that’s why even for the trust establishment between differenct participants there may be the need of a trusted third party, that would be superior to both RP and VCI, and represent the root of trust

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

Original Reporter: danielfett

Kristina Yasuda

2023-02-28

it should be explained why the focus is only on protocol and credential formats. technically, entity identifiers (DIDs, jwk thumbprints, etc.) are not part of credential format or protocol, but is crucial part of security, no? if entity identifier was considered as part of credential format it should be explicit.

secure implementations of cryptographic algorithms, the use of secure random number generators, the secure use of hardware-based storage

I have only seen sd-jwt define some of these… W3C VCDM definitely does not and not even mDL spec itself mandates HW-based storage.

something like implement securely and correctly as required by a trust framework would cover the introductory text better..

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

Original Reporter: danielfett

By Kristina and Giuseppe: https://bitbucket.org/openid/connect/pull-requests/468#comment-373434366

Kristina Yasuda

2023-02-27

in addition to misuse of the data, also that the wallet would manage the keys and claims in the credentials appropriately.

Giuseppe De Marco

2023-03-06

additional notes:

• the wallet is in the sole control of the user
• the wallet is compliant to the legal and technical requirements defined in the trust framework

‌

I'm having a problem with this.

Originally reported in https://bitbucket.org/openid/connect/pull-requests/468

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

Original Reporter: danielfett

By David: https://bitbucket.org/openid/connect/pull-requests/468#comment-376398590

(Re 2nd sentence:) This is not the case in general. Rather it is that the verifier can determine that the holder is entitled to present the verifiable credentials in the VP (and has not obtained the VCs by nefarious means). The holder may in fact control the subject e.g. when a parent holds the passport of a child.

(Re last sentence:) or to holders who are entitled to hold the VCs about the subject e.g. the owner of a pet, when the VC is the vaccination certificate of the pet

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

Original Reporter: danielfett

Regarding this open question: “Should a "presentation" always mean/require cryptographic holder binding? Should these use cases where it is not required covered by the protocol?”

Giuseppe De Marco

2023-03-06

it may depends by use cases.

presenting personal identification data, for authentication purpose, or verifiable attestation of attributes, for instance: diploma use cases and any other attestation, like mDL. In these cases the binding of the owner and the proof of it’s willing during the presentation is a mandatory requirement.

there are other cases where the VC is a cinema ticket, a parking ticket, laundry ticket and other cases where the credentials may be shared between different holders. In this cases there would not be the security requirement of the binding and that’s up to the nature of the credentials and service it is required to be used on.

usually, these VC/services, should be like disposable tickets, to be used only once.

Different cases are subscriptions or VCs which, by their very nature, must be resubmitted from time to time.

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

Original Reporter: danielfett

Kristina Yasuda

2023-02-28

what is an assumed relationship between issuer identifier and the key material used by the issuer?

Reading the sentence right after E-20,

If there are multiple instances of the same Issuer sharing the same key material, the Verifier must trust all instances equally. should probably be paraphrased as multiple instances of the same Issuer must be equally trusted by the verifeir only when they share the same key material.

tbh, instances of the same Issuer confused me…

Originally reported in https://bitbucket.org/openid/connect/pull-requests/468

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

Original Reporter: danielfett

By Kristina: https://bitbucket.org/openid/connect/pull-requests/468#comment-373433980

Re “Privacy (II)”:

“what about the wallet potentially knowing all of the presentation requests from various verifiers? not saying it is an issue, just trying to be a devil’s advocate, since I have heard that argument multiple times recently.”

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

Original Reporter: danielfett

Re storing end-user data

Giuseppe De Marco

2023-03-06

they should store the entire presentation to prove the willing of their presenter … otherwise multiple RP may “share” multiple VC between them without taking into account the requirement of having a proof of consensus of their legitimate owners (users)

national and comunitary data processing laws (such as the GDPR and EPDB) require the user's consent to be managed