Privacy requirement - how to provide and demonstrate the consent given to the RP to allow it to check the revocation status

[peppelinux]

We're going to implement this beautiful draft. Aside of our requirements already satisfied by the current text, we have debated about the following privacy concern:

• Once an RP has obtained the VP from a wallet instance, and the related status list ref related to one or more digital credential, the RP may continuously check the status of the credentials without any control/limit. This raises a privacy issue since an RP may control the mobile driving license of a citizen until this expire and completely out of the scope of the historical authentication made by the citizen to the RP, and the consent given.

another example: by asking the EAA related to an affiliation, an RP may check if a day a User was fired. And so on, exposing personal information that are not intended to be monitored/controlled over time.

This raised to our minds the requirement to protect the status endpoint for specific audiences and cryptographically, using sender-constrained tokens.

Since the User gives the consent for the presentation of the credentials, then the Holder should issue a grant token for accessing to the status of the credentials.

We take into account that the RS that hosts the status list MUST not inspect or know the identity of the requester (the RP) because it must not track the usage of a specific credential, owned by a citizen, to a specific RP.

Here some points of discussion to be further explored:

1. The RP MUST provide to the Wallet Instance an ephemeral key for each requested credential within the presentation request
2. the Wallet Instance issues a signed status list token, by signing it using the private key referred to the public one included in the credential cnf.jwk.
3. The status list token doesn't contains any information about the RP.
4. The signed status list token is provided to the RP with a PoP bound to the ephemeral key provided at point 1
5. the RP can only use that status list token to the RS that hosts the status list by cryptographically proving its possession
6. the RS that provide the status list doesn't know the identity of the client that consumes the status list
7. the status token expires in a short period (less than hours), taking out any possibility to grant the access to that anonymous client the status list for that specific credential
8. each time in the future the RP needs to check the status of a previously obtained digital credential, it MUST ask to the Holder (via email or any other digital delivery under the sole control of the User and offered by this latter to the RP) a presentation of that digital credential (by type)

in this way the user is always in full control of which RP is going to check the status of their digital credential.

Is there any idea, concern, issue, enhanchement to be considered before all?

If I miss something please don't esitate to bring me on the right path, I was quite far for a long time from this draft, then here my excuse in advance

[fmarino-ipzs]

Some use cases require the credential status to be verified only when the holder is presenting it. In this case an easier approach could be that the Wallet gets the status list signed with the timestamp and presents it to the verifier as a vp. If the verifier requires to check the status of the credential in the future then, following the comment of @peppelinux , the wallet provides a DPoP access token which should be opaque for privacy reasons and with this token the verifier can grant the access to the status list. This grant has an expiration date under the control of the user. Both approaches could be valuable.

[paulbastian]

Thanks for your feedback @peppelinux @fmarino-ipzs ! I understand your concerns and we are aware of them, as they are referenced but not yet fully written down in the privacy considerations section.

Towards your proposed solution:

• "Wallet Instance issues a signed status list token" -> beware that the term status list token is already used iun the terminology. I assume you mean that the Wallet Instance provides a sort of access token to the RP?
• "the RS that provide the status list doesn't know the identity of the client that consumes the status list" -> in reality I do not expect RP to obfuscate/reroute its request to the Status List Provider, so usually by the IP address the Status List Provider may have a clue who the RP might be. The main privacy benefit comes from the Status List Provider not knowing which particular credential status the RP is interested in, thats the herd privacy.
• How does the RS/Status List Provider in your case verify that the token is valid? It would need to know all the cnf.jwk that might sign such a token and in that way the RS can backtrack which credential status is actually requested and destorying the herd privacy

First of all, there might be lots of use cases that do not have a problem with this and for some usecases this might a feature, as the RP can recheck without needing to recontact the holder. The recheck might in some usecases not be a privacy problem, especially for all organisational identity related topics.

However, if this is a problem, I see in general 3 categories of approaching:

1. holder gives access token to RP
2. holder gives the whole status list to RP
3. RP authenticates to authorized status list

Regarding Option 1: I'm really unsure were this access token should come from and how the Status List Provider should verify it. If the access tokens are generated by the Issuer and given to the Holder, than the Issuer could easily link these tokens back to the Holder, destroying herd privacy. If the Wallet authorizes the status list access with a self-chosen access token that was exchanged during issuance and there is enough trust in the Issuer that he does not link those access tokens, then the wallet might sign a RP request by this way and it might be a solution(I think this is what you meant)

Regarding Option 2: In this case the Status List would need to be protected and the Holder needs some capability to access it. Again, the mechanism how this works will always allow the Issuer to link the request back to the Holder, therefore allowing the Issuer to track the usage of the issued credentials. If the Wallet authorizes itself with a self-chosen access token that was exchanged during issuance and there is enough trust in the Issuer that he does not link those access tokens, this is a solution.

Regarding Option 3: The RP authenticates and authorizes its access to the Status List. This gives the identity of the RP to the Status List Provider, but as I've written above, the identity might not be a secret anyway as the IP address of the request might be linked to the RP identity. By this means, only authorized RPs have access to the status list, yet they may recheck the status list more often, but it would be observable by the Status List Provider. Given that we aim for large Status Lists for better herd privacy, high volume RPs might anyway get constantly information on all the entities in the status list, even in a stricter regime like Option 1&2.

Option 1&2 puts a lot of trust in the Issuer, while Option 3 seems easier/better scalable

[peppelinux]

How does the RS/Status List Provider in your case verify that the token is valid? It would need to know all the cnf.jwk that might sign such a token and in that way the RS can backtrack which credential status is actually requested and destorying the herd privacy

this is a case where the issuer of the credential is the same that hosts the status list, then the credential and the revocation are linked within the issuer. The RP obtains a token signed by wallet instance using the private which the public part are referenced in the holder key binding of the credential cnf.jwk

The RP has a PoP for the use of this token, then it's a dpop token.

---

holder gives the whole status list to RP

the status list is then a static attestation of non-revocation, considering millions of issued PID this sounds very challenging in terms of payload size and signature costs of such big payload. This then should be valid within a short exp

---

RP authenticates to authorized status list

This brings back the privacy issue of the idp that knows which RP the user has just used in the present, since the RP must check the status list during the presentation phase

[peppelinux]

Here I propose a way to simplify the implementation, by removing the PoP from the grant token, issued by the wallet instances and provided to the RP for consume the status lists:

plantuml sources: here

Notes:

• the grant token is a bearer token signed by the Wallet Instance using the private key related to the public key used in the holder key binding of the credential
• the grant token should be provided within the vp token related to a specific credential. Then it is not SIOPv2 issuance because the RP does not ask for id tokens in the scopes of the request, the grant token is contained in each vp_token
• it should be short lived
• it is provided to the RP, that uses it as a bearer
• the Status List Server just has to validate the signature, having the proof that the grant token was signed by the legitimate holder

the grant token doesn't give nothing about the RP, but just:

iss: wallet instance entity id
aud: status list endpoint
iat: created
exp: valid until this timestamp
rsi: (revocation status uid) unique id of the revocation entry (index uid, whatever)

@paulbastian this proposal would be the 4th option, since the RP is anonimously authorizated to consume a specific status list entry

[peppelinux]

Regarding my previous proposal, nothing prevents us to include in the token a static state of the revocation, according to what we already have within the current draft

then rsi can be replaced with a status member, with a ref with or without a static chunk not to be intended as valid beyond the exp of the token that carries it

@fmarino-ipzs ^

[paulbastian]

But through the signature the issuer knows that there is a communication between RP and a specific wallet instance?

[peppelinux]

But through the signature the issuer knows that there is a communication between RP and a specific wallet instance?

I don't think so, in the limits that an RP would not be tracked though its IPv4 by the Status List Provider, because the token to consume the status list doesn't carry any RP identifier, it's just signed with the private key in possession of the holder related to the public key contained in the digital credential holder key binding. The RP uses it as a bearer token without any client authentication

[peppelinux]

@paulbastian looking for a good fit of the option 2, where the wallet instance provides the non-revocation attestation to the RP during the presentation phase, we have moved some initial steps in the definition of the revocation request flow (WI 2 Issuer) and non-revocation attestation request (WI 2 Issuer).

[peppelinux]

I would add that given that the previous proposal is related to the issuance and presentation of non-revocation attestations, I assume that the user authentication is not required for the issuance of the non-revocation attestation because attestation is not a digital credential

[paulbastian]

@paulbastian looking for a good fit of the option 2, where the wallet instance provides the non-revocation attestation to the RP during the presentation phase, we have moved some initial steps in the definition of the revocation request flow (WI 2 Issuer) and non-revocation attestation request (WI 2 Issuer).

This is similar to Option 2, similar to OCSP-stapling and similar to the concept named ValidityCredentials. In these cases you should not send the whole status list but only the status for the requested credential. It is a valuable alternative but is probably out of scope for the StatusList draft.

[paulbastian]

Option 1 seems complicated and has privacy iussues. Option3 does not solve the problem either but might be a feature

[peppelinux]

I would suggest to introduce and define the non-revocation attestation using the elements already defined in this specs and consolidate the option 2, at the same time start our considerations about the possibility to use these attestations as bearer tokens to enable the option 3 where the use cases requires it

[fmarino-ipzs]

I think we agree that any solution does not fit all use cases well. Given that, the best way forward is to start with the requirements and use cases and define a more general draft on Digital Credential Revocation, instead of focusing only on the representation of status lists. In this way, the different flows and processes could be defined according to the use cases and security, privacy and interoperability requirements (in light of EUDI Wallet as well). @paulbastian WDYT?

[paulbastian]

I think we have to discuss this with the other co-authors and at IETF Prague. We also plan to schedule a semi-regular open call, where these things could be argued.

[paulbastian]

@peppelinux @fmarino-ipzs I assume this issue is solved with your draft on status assertions? Pending close

[peppelinux]

Ok, the draf is here: https://datatracker.ietf.org/doc/draft-demarco-oauth-status-assertions/