Dependent claims should be bundled about vc-data-model

[David-Chadwick]

I dont think this is the right solution. Rather, separate claims should have a policy field which indicates the policy of the issuer. The policy may control the number of uses (e.g. one time use), restricted recipients (inspectors), or other controls. (Validity time is just one specific example of the issuer's policy.). Separating claims into atomic units is a good thing in my opinion as it allows the holder to aggregate them as he sees fit, and also supports 'least privileges' or 'identity minimisation'

[msporny]

Separating claims into atomic units is a good thing in my opinion as it allows the holder to aggregate them as he sees fit

Yes, agreed that this is a good thing. However, there will be /some/ issuers that do not want to atomize. They want their credential to be used only for the purposes they intended. Policy controls can be overridden if technology can't enforce the policy or detect when it's being broken.

We need to enable choice for BOTH the issuer and holder. This does create a tension between some issuers and some holders, but holders have the option of using an issuer that does atomize their claims vs. the one that chooses to not do so.

What may be happening here is a misunderstanding of what "dependent claim" meant when we had the discussion last year. "Dependent claim" means "a set of claims where the issuer does not want the claims to be separated from one another. For example, a Saudi Arabian Passport might be such a document. That particular government may not want you using the "over 21" part of the passport to get into bars due to its strict adherence to the interpretation of the Koran.

[David-Chadwick]

"Policy controls can be overridden if technology can't enforce the policy or detect when it's being broken".
I believe it is the policy of the inspector that ultimately counts. It might wish to override the policy of the issuer as it is taking the risk and bearing the cost itself. Real life example: Unilever issues me with a 10cents coupon off their soap, and it says 'only to be used to buy Unilever soap'. Tesco supermarket gives me 10 cents off my shopping when I hand in the coupon even though I did not buy any soap. So the issuer's policy is there to tell the inspector under which conditions it is prepared to honour the credential (and consequently bear any losses of the inspector if it made a mistake), whereas the inspector can choose to honour this or ignore it at its own risk.

"holders have the option of using an issuer that does atomize their claims vs. the one that chooses to not do so"
This is not always so. The Saudi passport is one such example. I cannot get this passport from an alternative issuer. It is also a good example of where the issuer's policy cannot be easily overridden: if the passport contains a whole set of claims that cannot be selectively disclosed to an inspector, then the young-looking Saudi citizen who wishes to frequent a bar has to do so by revealing everything about his Saudi identity, or not enter the bar, which is what the issuer wanted.

[dlongley]

This is not always so. The Saudi passport is one such example. I cannot get this passport from an alternative issuer. It is also a good example of where the issuer's policy cannot be easily overridden: if the passport contains a whole set of claims that cannot be selectively disclosed to an inspector, then the young-looking Saudi citizen who wishes to frequent a bar has to do so by revealing everything about his Saudi identity, or not enter the bar, which is what the issuer wanted.

True, but the user should get an atomic proof-of-age from a different issuer and use that instead. This is obviously a politically charged example. We can't enforce liberal ideals through this technology, we can only enable them. Perhaps we ought to focus on an alternative use case like academic course credit credentials where the "lab part" of a class can't be separated from the "lecture part".

[msporny]

There is a section in the spec now about dependent claims authored by @David-Chadwick: e18b205

Closing this issue.