Embedded Issuer Policies

[paulbastian]

For high-security usecases or use cases with sensitive data, some Issuers may want to require that VCs are only released to authorized Verifiers. One of the options to establish such a mechanism is to embed such a policy in the credential itself.

Do you believe this is something that should be solved by SD-JWT VC or does this belong into a profile / trust framework?

For example, an SD-JWT VC may contain a issuer_policy claim, that references a X509 PKI CA indicating to wallets that only Relying Parties authenticated with a certificate form this CA are allowed to receive a presentation of this VC.

[peppelinux]

interesting feature, it brings some requirements:

• definition of entity categories, a grouping of entities for specific purpose or compliance profile
• verifiable attestations/trust marks to proof the compliance of an entity to a specific purpose

I would not call it issuer_policy otherwise it seems that the subject of the policy is the issuer, while the issuer is the issuer and the subject is the credential, then credential_policy seems more appropriate if you agree. At the same time the issuer does not represent an authority in the trust ecosystem. The policy should be defined in a trust framework by trust authorities in a large ecosystem where multiple issuers operates. Ideally, the trust authority publishes the catalogue of the issuers granted for some credential issuances (eg: using OpenID Federation we have trust_mark_issuers that maps trust mark ids with entities id).

In your proposal once the wallet has obtained the credential, evaluates the credential_policy to kow to which entity categories it can present it.

The RP should send a presentation request providing the trust mark/verifiable attestation that give the proof of its compliance to some profile/entity categories enabled in the credential_policy. Then the wallet evaluates the trust with the RP, then evaluates the Trust Marks and present the credential.

the model you propose is interesting but can be simplified and make more flexible by saying that:

• the credential_policy should be provided in the credential definition published in the issuer metadata, preventing the revocation of the credential when the policy might change in the future (or be extended with additional audiences)

the requirement of the trust-markls/verifiable attestation remains for the RP.

a question is: is these policy enables with a sort of policy language (as the openid federation metadata policy) or are static and audience focused?

[bc-pi]

Do you believe this is something that should be solved by SD-JWT VC or does this belong into a profile / trust framework?

I don't know, to be honest, but my intuition is that SD-JWT VC isn't the right place. I'm not sure putting that kind of policy in credential itself is the right place either.

[Sakurann]

we did have a use-case where the issuers wanted to ensure that credentials are not being used by unauthorized verifiers, and wanted to ensure that by including legal policy reference inside the credential.

[danielfett]

It seems that there is not much interest in this topic, at least it has not come up in any discussions in the last months. Unless there is a really good use case, we will close this issue.

[bc-pi]

It has been suggested that there might still be interest in this topic. But the path forward is still unclear (at best). The aud claim could potentially be (mis)used for this? Or nothing here at this layer. Or expressed in metadata. Or part of a vct or sub-vct definition.

[paulbastian]

From the eIDAS implementing act proposals there is:
(12) ‘embedded disclosure policy’ means a set of rules, embedded in an electronic
attestation of attributes by its provider, that indicates the conditions that a wallet
relying party has to meet to access the electronic attestation of attributes;

[c2bo]

Recent discussions about transaction data in OpenID4VP have also brought up the topic of issuer policy regarding intended usage (not only allowed audience) of a credential (openid/OpenID4VP#197 (comment)). Should this be a new issue or do you think it fits in this one?

[alenhorvat]

This issue seems to be related to the discussion: openid/OpenID4VP#232

IMO, there are 2 options going forward

• defining how to express policies in this specification
• leave it to the "trust framework" by allowing custom claims to express different policies

If this specification is/plans to be decoupled from the VC issuance/presentation protocols and/or trust frameworks, option 2 should be considered.

We introduced an approach: https://hub.ebsi.eu/vc-framework/trust-model/policies, but this approach is exchange-protocol dependent (at least query language dependent), which comes with limitations and certain specification lock-in.

[awoie]

This issue seems to be related to the discussion: openid/OpenID4VP#232

IMO, there are 2 options going forward

• defining how to express policies in this specification
• leave it to the "trust framework" by allowing custom claims to express different policies

If this specification is/plans to be decoupled from the VC issuance/presentation protocols and/or trust frameworks, option 2 should be considered.

We introduced an approach: https://hub.ebsi.eu/vc-framework/trust-model/policies, but this approach is exchange-protocol dependent (at least query language dependent), which comes with limitations and certain specification lock-in.

I'm in favor of option 2. I think it is really hard for us to anticipate how to encode these policies. We would end up having something that W3C VCDM has which is an extension point for policies (they call it terms of use) without actually defining them which has not much value because it has to be defined per trust framework or ecosystem anyways.

I'd be in favor of adding an example of how this can be done without providing normative statements.

I understand there are protocol-specific features that require things in the SD-JWT VC but I was wondering whether it makes more sense to have a profile of SD-JWT VC for these protocols which defines a common set of claims to support these protocols. OID4VP transaction_data could be one of these features. Another example might be session_transcript (b64u-encoded CBOR blob) if SD-JWT VC is used with ISO 18013-5.

Any thoughts? @c2bo @alenhorvat @paulbastian

[alenhorvat]

You could define a generic placeholder "policies" (pol?) with a "typ" or "type" member, where typ/type value is either registered in IANA or is a private value defined by the framework.
Policy can be embedded or referenced (URL + digest). Whether the policy is machine readable or not, depends on the use case.

Similar to RFC7800.

(I think ETSI defines some policies for x509, so they may include the x509 itself or translate them to JSON)