age_over_18 in PID minimum data set

[peppelinux]

In the new version of the ARF 1.2, the mandatory set of user attributes for the PID has been changed, do we need to be compliant with that? they considered age_over_18 as a mandatory attribute in the Italian PID?

_Originally posted by @asharif1990 in https://github.com/italia/eudi-wallet-it-docs/pull/123#discussion_r1322095320_

[balanza]

Good point. Besides the attribute being mandatory in the ARF, it does challenge our PID issuance process as forces us to invalidate the credential in the very exact moment the user turns 18*.

Given the PID requires strong authentication from the user, it cannot be issued silently; that is, an actual request must be initiated by the user. We're actually invalidating thousands of users' wallets at every midnights, like Cinderella's pumpkin carriages.

What's the discussion about this on the ARF? I see the value in terms of minimum information disclosure, still I argue it poses several challenges to Wallet usability.

_(*) That applies to all the age_over_NN attributes, which are not mandatory._

[peppelinux]

the way you exposed has raised several concerns in the standardization tables, since as you mentioned when you find an age over with a short iat, then you can definitively know the date of birth of the user

that's why I had suggested that iat should be SD (@Sakurann) but unfortunately I didn't convinced the authors, as you can see: https://github.com/vcstuff/oauth-sd-jwt-vc/blob/main/draft-ietf-oauth-sd-jwt-vc.md#registered-jwt-claims

that would suggest to rehint the issue?

[peppelinux]

@balanza you should check the pid rulebook and not the published release of the ARF to get the relevant and fresh information about the next version of the ARF

[balanza]

@balanza you should check the pid rulebook and not the published release of the ARF to get the relevant and fresh information about the next version of the ARF

I was referring to ARF 1.2 (6.2.1.2). Do you mean another source?

[balanza]

that iat should be SD

Good catch, didn't think about it. Also exp, in case you want to issue a credential that expires on user get older than 18.

---

Anyway, do we agree this is not just another data field, but it brings several concerns to the credential itself? Should we elaborate an alternative to propose to ARF?

[peppelinux]

Yes, please on a separate call we may elaborate a proposal for the ARF anyway

However, for the implementation profile we're landing, I don't see any requirement to revoke or expire the PIDs exactly the day of the birthday, what do you think if the wallet instance inform the user that he/she is got older and should renew its PID?

this would keep this issuance actionable by the user and under its sole control.

Interesting issue.

[balanza]

what do you think if the wallet instance inform the user that he/she is got older and should renew its PID?

I think the PID (an any credential) MUST NEVER ship false informations. The very day you turn 18 the statement age_over_18=false is false, thus the PID itself must be invalid. It's up to the issuer to include such policy in its credential lifecycle management (for example, by issuing the PID with a thoughtful exp).

Of course the Wallet Instance should try to make it smooth for the user, providing right guidance and informations.

[balanza]

@peppelinux what we may want to elaborate - although I think is very premature for now - is a predicate mechanism to allow zero-knowledge proofs. I don't know if there are ongoing discussions already for the subject.

By using static, selective-disclosable attributes for values that changes over time, I think we are stuck on having credentials that need to be re-issued periodically.

[peppelinux]

Here a predicate example using static linked hashes

the wallet instance obtains a PID with two claims: zero_age_hash and current_age_hash.

now the wallet makes the sha256 of the zero_age_hash and then the sha256 of the last hahed value making an array of linked hash untill it produces the hash that matches to the current_age_hash.

the wallet presents the PID to an RP that need to know is the user is over 5 years :-), then question is: are you at least 5 years old?

the wallet presents the disclosed current_age_hash 16cd52f9a8c9922b96614611b37b9399282fc8adc8071c3b746c0002b52cfe2a signed by the issuer, and a self signed hash that we may call first_useful_age_hash 03cd170dd0d12e87bf8197883ae253a77a50bc46b78df3c9a330422a121b0caa

now starting from first_useful_age_hash (issued by the wallet), the RP makes a concatenated sha254, i.e. create a sha of the value obtained to produce the sha of the next value, obtain this chain until reaching the hash issued and signed by the issuer, and get this chain:

03cd170dd0d12e87bf8197883ae253a77a50bc46b78df3c9a330422a121b0caa
2769ed46cc42d0666fb6300b2b7dd6bc95681eba24425ebabe3e86203801a766
02165ecf2561a4c8721f26a83166499ea2f833af58355421a3b7e883668eec5a
eb61c709c5243e63bdae16ca0e9eaf24b1cbc9fbe7f19e0d6e0f714ac650dd42
ce0fd1abc1e2a2d46066f37687902a0b7e0dee90edd2f7a43a1a9ff8b7ed91f7
16cd52f9a8c9922b96614611b37b9399282fc8adc8071c3b746c0002b52cfe2a

The RP counts the elements of the chain, there are 6. Well, here is the predicate of the age over 5.

The issuer signs the hash of your current age, hashes are not reversible. The wallet gives you a hash corresponding to the first useful age, starting from the latter the verifier produces the chain until it corresponds with the hash issued by the issuer so, recap

Hash of current age of 40 first useful age hash is 22 I count from 22 to 40 and I get 18

The problem with this solution is that we have resolution in years, and not in months/days, but it would not be too mush difficult finding a way to handle the months at the borders.

[peppelinux]

@balanza here the ETSI paper on ZKP and advanced ways to issue predicates without personal data dislosure https://www.etsi.org/deliver/etsi_tr/119400_119499/119476/01.01.01_60/tr_119476v010101p.pdf

[balanza]

@balanza here the ETSI paper on ZKP and advanced ways to issue predicates without personal data dislosure https://www.etsi.org/deliver/etsi_tr/119400_119499/119476/01.01.01_60/tr_119476v010101p.pdf

I will give a closer look, thanks.

---

The approach in https://github.com/italia/eudi-wallet-it-docs/issues/124#issuecomment-1736451780 still makes the PID expire: next year your current age will be 41, thus data in the credential won't be true 🤷

[peppelinux]

@balanza the problem that you raised is the evidence that the users may use to request the issuance of their new pid each day of their birthday, in particular when they get ager over 18

[peppelinux]

we agreed that all the age over attributes must be taken in a specialized EAA