Static Trust negotiation in a scenario where Verifier is offline

[Giuseppe De Marco]

Goal
Propose a way to trust a RP without any possibility to query a ledger or any other public infrastructure in real time.

Hypothetical scenario
Bob requests a VP to Alice establishing a link of proximity with NFC, bluetooth, wifi LAN, etc.

Problem
Alice doesn’t have a broadband connection, she doesn’t know who Bob is and she has no reason to trust him.
In these conditions the VP won’t be released by Alice to Bob, Alice’s Wallet alerts her because it can’t trust Bob (as today web browsers does with untrusted https certificates, anyway the user can confirm to continue if the user want do that).

Requirement
A mechanism that allows Alice’s Wallet to trust Bob, even in absence of an internet connection.

Solution
A signed Badge (as Trust Marks in OIDC Federation) is presented in the registration objects, in the authz request. This Badge is signed by a trusted issuer. Alice’s Wallets periodically updates all the public keys of the trusted issuers of badges. Bob’s Badge has an expiration timestamp, Bob periodically download all his updated badges before they expires.

In this way Alice’s Wallet can statically verify the signature of Bob’s badge having the proof that Bob is recognizable by a trusted third party, which is the badge issuer.

Limits

If Bob is excluded and loses his badges, Alice won’t be able to get Bob’s exclusion without an internet connection, until the badges issued to Bob expire. With a fairly frequent update policy of badges (24-48h) and a regulation of the times of exclusion of a subject, the risks do not seem to be relevant.

[David W Chadwick]

I think that what you are suggesting is a subset of “trust negotiation”, a well researched topic. In this scenario all parties have credentials (badges) that they are willing to release to the public (could be none), in order to form a basic level of trust, and from this, can request additional credentials from the other party. They also have policies for which credentials they require from others in order to release their own credentials. In this way trust can be increased through trust negotiation. The skeleton for this protocol is already in place with the OIDC4VP spec and the enhancement you are suggesting, in which the RP (Bob) can send its public credential plus its DIF PE request for additional credentials to the SIOP (Alice), and Alice can return her public credential plus other (non-public) ones based on seeing the public credential of the RP. The SIOP’s response should contain the DIF PE request of Alice saying what she requires from Bob in order to release additional credentials. For example, say Bob and Alice are willing to publicly announce they are UK citizens, and each have a policy that they will release their employment credential to other UK citizens. So Bob says to Alice “I am a UK citizen, who do you work for?”. Alice replies “I am also a UK citizen and I work for CCP”. Alice also says to Bob, “who do you work for?”. Bob replies, “Uk Tax authorities, and can you send me your tax code”. Alice will have a policy saying she will release her tax code to the (certified) tax authorities. I am sure you get the picture from this scenario.

[Giuseppe De Marco]

Yes David, but offline, Alice only has the public key of all the authoritative badge issuers (or public credentials). Bob comes with a badge, Alice statically validates the signature and knows that Bob is compliant to a some minimum requirements, without which Alice’s wallet should reject the request (or filter it by displaying a warning to the user)

[David W Chadwick]

All trust systems have to have some way of configuring their roots of trust out of band. So a wallet is no different to an RP in this respect. Therefore one might expect a wallet to have a set of preconfigured trusted issuers. In fact with trust negotiation, one can regard the users Alice and Bob as alternating between the roles of RP and SIOP, so both need to have a list of their trusted issuers.

[Giuseppe De Marco]

In terms of implementation I propose to have the badge/public-credential in the metadata of the RP, in its SIOPv2 registration parameter (if offline).
What would be the alternative, or better the current solution, to achieve the goal of this static trust negotiation?

I didn’t see that in OIDC4VP, do you have a pointer?

[David W Chadwick]

Your solution is OK for a transaction between a person (SIOP) and organisation (RP) but I was suggesting a solution for peers, where each party can be a person, and alternate between the RP and SIOP roles. I don't see people publishing their static RP metadata containing their credentials in the same way that an organisation RP will, do you?. However I do see people publishing their badges in LinkedIn (which they already do today), so that Alice can find Bob’s credential without talking to Bob. In this case OIDC is not necessarily needed.

You are correct that the current version of OIDC4VP does not have credentials flowing from the RP to the SIOP (other than a X.509 PKC in the Internet flow).

[Giuseppe De Marco]

first of all, Thank you for staying on track as usual!
I rather want to cover just the use case of person who asks a document to a another person.

Another example, suppose a qrcode ... at the cinema entrance, which allows all users to send the VP of the green certificate.

Well, in the request I would identify within the SIOPv2 metadata, through the submission of the registration parameter, a claim where to expose one or more of these badges.
I’m looking on how to get this in SIOPv2, why OIDC would not necessarily for this?

I mean that a verifiable presentation should presented as a response to an authoritative request, in this case the user is aware and wallets knows (and may log) to which requesters has given the VPs

[David W Chadwick]

My feeling is that both of your examples can already be implemented using SIOP, without the need for the RP to present any credential. This is because trust can be established out of band. In the cinema case by the donor being present at the building and assuming that the QR is trustworthy. In the person to person case by the RP who requires the document proving to the donor why they can be trusted e.g. it might be a policeman in a uniform, a security guard at a door etc. If some random stranger stopped me in the street and asked me for my driving license then of course I would need proof that they were entitled to see it, but I could do this by running an RP app on my phone which sends a OIDC4VP request to them first. After they have sent me their badge, then I can send my credentials to them using the existing SIOP mechanism.

[Giuseppe De Marco]

Sounds great, in an offline scenario where the request is exposed in a static QRcode:

1. if exposed by a smartphone of an operator, at the entrance of a structure for example, the holder may send a request to the verifier (link of proximity) to obtain a VP and validate the signature of this having the pub key of all the trustworthy issuers.

2. if exposed to a wall, as a static representation (eg: public transport ticket service, donation to an NGO, etc) the holder MUST use the broadband connection to request a VP to that Verifier or simply resolve its DID to a trusted ledger.

the solution proposed by you I assume that Alice has a broadband connection or any other kind of link of proximity that lets here to interact with the verifier (RP). Once her Wallet has framed the QRcode it could checks the authenticity of the RP, sending to it a VP request. This could like the following picture.

The alternative I proposed would be a VP/badge in the RP metadata (SIOP registration parameter). In an offline scenario the [opt trust negotiation] would not happen or could happen optionally, in addition. The VP/Badge in the RP metadata would be the first necessary evidence to assess the authenticity of the applicant.

‌

[David W Chadwick]

I like your diagram very much, thankyou. Note that the user can send the opt VP request of the trust negotiation by displaying a QR code on her smartphone by using a verifier app (in the same way that the RP did initially). Thus the user is switching roles from Wallet to RP. Both roles could be combined in one app, or could be separate apps.

The only issue I see with your solution is the size of the QR code since it presumably must use the registration option rather than the registration_uri option, and including a VP/badge in the QR code along with the other registration parameters might be too much to encode in a single QR code.

[Giuseppe De Marco]

thank you, I included the link with the editable sources.

I agree about the “ability” of a Wallet to shows a QRcode to a Verifier to start a trust negotiation, even if it presents some UX issues and needs more study about how to let the user be friendly with this mechanisms of async exchange of qrcodes, where the second one is linked to the first one (and when the roles of holder/verifier accordingly switches). Having the VP/badge directly in the registration metadata all this exchange would be useless (UX pros).

I’d like to see wallets implementations that embed both holder (SIOP) and verifiers (RP) to prevent application hijacks in a single mobile device (that would introduce the issue of how an app may trust another one).

Regarding the QRcode maximum size, we should fit in 3k and they seems to me good enough for a authz request with an embedded registration paramenter in SIOPv2.

It seems that we understood each other perfectly, it remains to be determined whether the possibility of obtaining VP/Badge/or other-signed-artifacts within the register metadata can fit into SIOPv2 specs or not.

at this point it would be interesting to listen to the opinions of the other experts

[Kristina Yasuda]

I think app attestation is what we have been exploring to solve this issue, and I would like us to converge there? PR #157

[Giuseppe De Marco]

using a signed JWT request object in a SIOPv2 Authz request we can establish the trust to a RP using OIDC federation or a direct trust to the Certificate chain (x5c).

The problem issued here is that a request MUST be encoded in a QRcode or any other way that enables a HTTP GET request (or any other allowd by a RF link using BT, NFC …) and that a x5c (with certificates of a length of 4096 bit) can exceeds the maximum length of a standard HTTP GET Request or any other QRcode maximum size (3k).

What we achieve in the PR 157 concerns the credential issuance endpoint, and implementes a trust negotiation via a HTTP POST method, and that’s fine.
What I exposed in this issue is related to the authz request of a RP to a SIOPv2

[David W Chadwick]

Kristina. I think these are two separate issues. PR#157 is about trust between the wallet and issuer, but this is wallet trust in the RP

[Giuseppe De Marco]

probably we can elude the maximum request size using x5t but this forces the wallet to download in a previous time all the trustable certificates and that’s something huge to get implemend concretely.
If we may have a VP (or any other equivalence of trust mark/badge as a signed-JWT) that’s signed by an authority, well the wallet may have only the public keys of the trustable issuers, that would be way to verify the requester.

The lookup claim, in the signed JWT, would be the claim kid or x5t. The iss parameter in the JWT would help the lookup process to let the wallet get the public key related to that issuer, previously stored in the wallet.

‌

[Kristina Yasuda]

Clarified that this is a scenario when the Verifier is offline in the issue #1499

[David W Chadwick]

I think this issue is related to #1511 for the following reasons. If the wallet is pre-configured with the trust federations that it trusts (or is a member of) then if the QR code contains the trust federation membership asserted by the RP, then it does not need to be a JWT or be cryptographically verifiable (it can be a false assertion, this does not matter as the wallet will validate the assertion). All the wallet needs to do is authenticate the identity of the RP (which requires cryptographic proof) then pass this plus the asserted federation membership to its federation membership API and it will get back a true or false response, indicating if this RP is a member of the trusted federation.

[Kristina Yasuda]

I think Verifier Attestation JWT proposed in PR #524 is similar to Giuseppe’s proposal here and would solve the problem?

[Giuseppe De Marco]

Yes, i can close this right now

Now we have the trust chain jws header parameter and the attestations that in federation can be issued as trust marks and that can work also without federation until there a secure underlying trust mechanism