PE Simple Profile

[David-Chadwick]

Please find attached a simple profile for PE for discussio
DIF CNF Profile.pdf
n

[bumblefudge]

At the risk of sounding like I'm missing the point of a subset-profile or being directed to section 3, I have to ask: Is this essential?

The frame property MUST NOT be present

If I'm understanding correctly the function of frame, this would exclude mutual support for the WACI-PEx profile, and any kind of BBS+ or other LD-based selective-disclosure VP being used to subset a larger VC. Would it be possible for frame, or for that matter any of the fields listed in Section 3, be safe to ignore if present?

[David-Chadwick]

To be honest I do not understand the function of LD Frame property, but I do not think it is relevant to this profile for two reasons.

1. This profile should be usable by pure JSON implementations that do not understand JSON-LD.
2. The purpose of this profile is to request VCs from a user's wallet, and those VCs should be held as credentials (as defined in the W3C VC Data Model) with internal or external proofs. So the type of proof is not relevant to this profile. Consequently the format of the VP is not specified in this profile. How the wallet creates the VP from the VCs, in order to match the PD, is outside the scope of this profile. The proof formats that wallets and verifiers support are obtained from published meta data and not from this profile.

[nklomp]

Hi David,

As you are aware I am pro having a simple profile like this, as implementing the full spec comes with quite a lot of intricacies, so thanks for writing it down.

I do have some questions/remarks

Formats (2.1)

You mention:

This profile does not cater for credential formats other than the W3C VC format
And then in 2.1 there is the removal of the format. What does the W3C VC format mean here?

The jwt_vp, jwt_vc and ldp_vc, ldp_vp formats, all conform to the W3C datamodel. To me it makes sense as a verifier to communicate what type(s) you are supporting. Without it you are basically expecting that every verifier using this profile should support both the JWT and JSON-LD world

Selective disclosure (2.3)

Are you removing the limit_disclosure required to make it simpler for implementations that will not support selective disclosure on the holder side, since they can simply provide the full credentials if the value is prefered? That does limit verifiers that really don't want additional fields as they cannot mark it required

Frame removal (2.1)

Already addressed above. Since the profile allows for selective disclosure, I think it should also allow the frame property to be there. If the limited_disclosure is set to prefered and you do have an implementation that can do selective disclosure it might want to use the frames. If it doesn't support frames/selective disclosure, no harm would be done, as the full VCs would be submitted

Removal of types (2.3)

I do get you want to keep it as simple as possible, but I am not sure whether omitting 2.3 types should be in there.

I expect that to be one of the most widely used ways of narrowing down to one or more credential types for simple use cases. "Just give me a credential conforming to this type". I also don't think it makes it more complex because it is similar to fields with filters, which are supported by the profile as well.

Field ids (2.4)

What is the reason you are removing the id? It was already a MAY in the spec. If a wallet/agent does not support ids and they are provided in the definition nothing goes wrong right? Some implementations might be using these ids if present. I do not see the benefit of removing them.

PS.
Does it make sense to create a Markdown file of it and create a PR, as then the discussion can happen more inline?

[David-Chadwick]

Hi Niels
Answers to each part below

Formats (2.1)

The VC and VP formats that the wallet and verifier support are determined either out of band or in the protocol that wraps this profile request and response. The profile itself is independent of the proof formats that the credentials are protected with. This makes the profile only dependent on the contents of the credential and not on the format of the verifiable credential. Furthermore the profile makes no statement about the format or contents of the VP. It only says which VCs it requires (optionally selectively disclosed).

Selective Disclosure

The answer is yes. The verifier is saying "i want a vc containing property b" and the wallet is returning a vc containing properties b and c, so the verifier can simply discard c. This is in line with the robustness principle: be conservative in what you send, be liberal in what you accept.

Frame Removal

As stated above, this profile only controls what the verifier wants, but not how it wants it. How the VP is packaged up, with our without frames, has to be determined either out of band or in the transporting protocol

Removal of Types

I believe this is being dealt with in PE by removing the types parameter. So we can remove this from the profile once PE has removed it from its specification

Field IDs

It is not clear to me why the field id is needed. What purpose does it serve? Without a clearly defined purpose, surely it is superflous to a simple profile.

Markdown

This has now been created and is PR#275

[David-Chadwick]

Hi Niels thankyou for your comments. Answers below On 25/11/2021 16:50, Niels Klomp wrote: Hi David, As you are aware I am pro having a simple profile like this, as implementing the full spec comes with quite a lot of intricacies, so thanks for writing it down. I do have some questions/remarks Formats (2.1) You mention: This profile does not cater for credential formats other than the W3C VC format And then in 2.1 there is the removal of the format. What does the W3C VC format mean here? The jwt_vp, jwt_vc and ldp_vc, ldp_vp formats, all conform to the W3C datamodel. To me it makes sense as a verifier to communicate what type(s) you are supporting. Without it you are basically expecting that every verifier using this profile should support both the JWT and JSON-LD world The W3C standard recognises two types of data structure: - those without a proof property (called credentials and presentations) -those with external or embedded proof properties (called verifiable credentials and verifiable presentations). I have designed the profile to only consider the first type, so that it is independent of the proof format and therefore applies to all types of proof (even ones that have not yet been specified e.g. a cbor proof). The idea is that the protocol for carrying the presentation profile will specify the proof format that is required, so that different RPs that support different proof formats (and different protocols) can still use the same profile instance to specify the credentials that they want. Selective disclosure (2.3) Are you removing the limit_disclosure required to make it simpler for implementations that will not support selective disclosure on the holder side, since they can simply provide the full credentials if the value is prefered? That does limit verifiers that really don't want additional fields as they cannot mark it required Correct. The idea is to make it as simple as possible for holders. I dont think this limits verifiers as they can simply discard extra information that they don't require. Since they are saying what their preferred attributes are, they are complying with GDPR by not asking for more than they want. Frame removal (2.1) Already addressed above. Since the profile allows for selective disclosure, I think it should also allow the frame property to be there. If the limited_disclosure is set to prefered and you do have an implementation that can do selective disclosure it might want to use the frames. If it doesn't support frames/selective disclosure, no harm would be done, as the full VCs would be submitted Another objective is to remove any knowledge of JSON-LD from implementors and implementations. My understanding is that Frames are a JSON-LD feature. We were very careful when specifying the W3C VC Data Model to allow it to be implemented by programmers that knew nothing about JSON-LD and for VCs to be created and validated without using any JSON-LD tools or methods. So the current profile caters for implementations that do support selective disclosure but do not support JSON-LD. Conversely it can still be used by implementations that do support JSON-LD (it just wont use any of these features) Removal of types (2.3) I do get you want to keep it as simple as possible, but I am not sure whether omitting 2.3 types should be in there. I expect that to be one of the most widely used ways of narrowing down to one or more credential types for simple use cases. "Just give me a credential conforming to this type". I also don't think it makes it more complex because it is similar to fields with filters, which are supported by the profile as well. As I read it, the current PE spec has duplication, since there are two different ways of specifying exactly the same requirements in terms of types that are required. Therefore the verifier can use the fields parameter to specify the types they want. This simplifies it for the holder since they only need to parse the fields parameter and have a single way of understanding the RP's requirements. Field ids (2.4) What is the reason you are removing the id? It was already a MAY in the spec. If a wallet/agent does not support ids and they are provided in the definition nothing goes wrong right? Some implementations might be using these ids if present. I do not see the benefit of removing them. Unless I am mistaken, field_id is only used for the more complex filtering rules of same_subject, is_holder etc and since these rules are excluded from the profile then the field id serves no purpose PS. Does it make sense to create a Markdown file of it and create a PR, as then the discussion can happen more inline? Yes it would, but I am not an expert in creating the Markdown file. I would be happy to do this with a bit of hand holding. Kind regards David — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#269 (comment)", "url": "#269 (comment)", "name": "View Discussion" }, "description": "View this Discussion on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]