Adopt Presentation Exchange as an officially supported mechanism within SIOP
Issue #1230
resolved
DIF Presentation Exchange (identity.foundation) has now been adopted by all major VC-focused standards organizations and industry groups. As I see more and more duplicative proposals, Issues, and spec details popping up in this SIOP work, it’s becoming clear we need to regroup and reassess those aspects of the SIOP initiative. I am unclear why the PE primaries were not pulled in to ensure uptake of these cross-compatible specs, but the time is now to reorient. We can accelerate this entire SIOP initiative by leveraging the work the community has done in DIF. This is an umbrella decision that should be addressed as both a top-level proposal and individual, targeted issues that resolve the duplicative activities in favor of the existing solution.
Comments (42)
-
-
reporter
- edited description
-
Thanks for bringing this topic up.
The authors of OIDC4VP (https://github.com/awoie/vp-token-spec) have been thinking about incorporating PE as building block to benefit from the previous work done at DIF. We are seeking for the simplest possible way to leverage VPs via OIDC that can easily be used by any developer according to OIDC’s principle of “making simple things simple and complex things possible”.
However, it seems PE has a lot of overhead in comparison to a OIDC “native” solution due to the transport agnostic and flexible approach taken. OIDC already has a mechanism for requesting claims and ways to deliver them. What is needed in my opinion are ways to request credentials/presentations (including specific claims from those - selective disclosure) and places and representations to deliver them. As far as I see, elements of PE could address the first requirement (through primitives in input_descriptors and submission_requirements) but does not address the latter.
Could you please explain how you envision DIF PE to be integrated with OIDC in a developer friendly way?
-
Copied in from a email thread so that the thought is not lost - from David Chadwick
Hi Daniel
The problem I have with the DIF Presentation Exchange is that it mixes up the semantic level with the syntactic level. Administrators who specify WHAT claims they want are working at the semantic level, and this should be in the DIF data model, whereas protocols that say HOW this should be exchanged and say how they want claims to be formatted are working at the syntactic level.
It has been said that PE is a data model and not a protocol but I dispute this because of the above mixing of layers.
DIF PE does not help interworking because it allows the RP to request claims in one format (or to not specify any format) and the client to return them in a different format that the RP cannot support. PE would serve the community much better if it simply stated which claims are needed and stayed at the semantic level.
Thus I think DIF PE needs to remove all its contents about claim encodings and allow this to be specified in the protocol layer where proper negotiation can take place, or none if a particular protocol mandates a particular format always be used.
Otherwise the way that PE specifies which claims are needed is pretty comprehensive, even if it is somewhat complex and overkill for the vast majority of use cases (although I admit that much of the complexity can be omitted if it is not needed.)
==== end of davids note. ====My concern.
1. PE is built to go between an RP and an Wallet where the RP already knows the user’s did and which wallet it is communicating with.
2. OIDC must be able to function as a part of interchange with the RP not even knowing who the user is. Potentially the buttons on the RP could determine that the user wanted to use a self-issued ID, but not much more.
3. So the question at hand is how the RP could craft a request without even knowing if the PE was even possible?
Potential Path forward: For starters perhaps we could select an actual use case which was provided by the DHS S&T challenge. The user has been offered a job and needs to provide strong ID and proof-of-employability. I will presume that the user goes to the employer’s web site for instructions on what to do next. What message is created by the RP when the user selects self-issued ID?
-
@Torsten Lodderstedt
I think the concrete proposal is the following:
- In the request, use a Presentation Exchange structure below inside the claims parameter :
{ "id_token": { "presentation_definition": { "id": "32f54163-7166-48f1-93d8-ff217bdb0653", "input_descriptors": [ { "id": "ContosoUniversityCredential", "schema": { "uri": ["https://www.w3.org/2018/credentials/examples/v1/IDCardCredential"] } } ], "format": { "jwt_vp": { "alg": ["RS256", "ES256", "ES256K", EdDSA"] }, "ldp_vp": { "proof_type": ["Ed25519Signature2018"] } } } }instead of using verifiable_presentations.credential_types (in section 6 and 8.1):
{ "id_token":{ "verifiable_presentations":{ "credential_types":[ { "type":"https://www.w3.org/2018/credentials/examples/v1/IDCardCredential", "format": { "vp_jwt": { "alg": ["RS256", "ES256", "ES256K", EdDSA"] }, "vp_ldp": { "proof_type": ["Ed25519Signature2018"] } } } ] } } }Above examples are all the required parameters + optional
formatparameter.2. In the response, use a Presentation Exchange structure below :
{ "presentation_submission": { "id": "a30e3b91-fb77-4d22-95fa-871689c322e2", "descriptor_map": [ { "id": "ContosoUniversityCredential", "path": "$.attestations.presentations.ContosoUniversityCredential", "format": "jwt_vp" } ] }, "attestations": { "presentations": { "ContosoUniversityCredential": "<VP in a JWT format>" } } }instead of the current container format (section 5):
{ "format":"vp_ldp", "presentation":{ <VP in a JWT format> } }@Daniel Buchner
@Daniel Buchner
, correct me if I am wrong.
-
@Kristina Yasuda
While I see some benefit in introducing elements of a presentation-definition to our draft. I don’t see a benefit in using the presentation submission. First, we don’t need the indirection facilitated by presentation submissions since the RP defines the places where it wants to pick the VPs up in the request. That’s simple and deterministic from a RP’s perspective. Second, I don’t know how PE would be supposed to work with the vp_token.
Example Request for id_token
{ "id_token": { "verifiable_presentations": { "input_descriptors": [ { "id": "ContosoUniversityCredential", "schema": { "uri": [ "https://www.w3.org/2018/credentials/examples/v1/IDCardCredential" ] } } ], "format": { "jwt_vp": { "alg": [ "RS256", "ES256", "ES256K", "EdDSA" ] }, "ldp_vp": { "proof_type": [ "Ed25519Signature2018" ] } } } } }Response
{ "kid": "did:ion:EiC6Y9_aDaCsITlY06HId4seJjJ...b1df31ec42d0", "typ": "JWT", "alg": "ES256K" }.{ "iss":"https://self-issued.me", "aud":"https://book.itsourweb.org:3000/client_api/authresp/uhn", "iat":1615910538, "exp":1615911138, "sub":"did:ion:EiC6Y9_aDaCsITlY06HId4seJjJ-9...mS3NBIn19", "auth_time":1615910535, "nonce":"960848874", "verifiable_presentations":[ { "format":"vp_jwt", "presentation":"ewogICAgImlzcyI6Imh0dHBzOi8vYm9vay5pdHNvdXJ3ZWIub...IH0=" } ], "sub_jwk":{ "crv":"P-384", "kty":"EC", "kid": "c7298a61a6904426a580b1df31ec42d0", "x":"jf3a6dquclZ4PJ0JMU8RuucG9T1O3hpU_S_79sHQi7VZBD9e2VKXPts9lUjaytBm", "y":"38VlVE3kNiMEjklFe4Wo4DqdTKkFbK6QrmZf77lCMN2x9bENZoGF2EYFiBsOsnq0" } }Example for vp_token
{ "id_token": { "email": null }, "vp_token": { "input_descriptors": [ { "id": "ContosoUniversityCredential", "schema": { "uri": [ "https://www.w3.org/2018/credentials/examples/v1/IDCardCredential" ] } } ], "format": { "jwt_vp": { "alg": [ "RS256", "ES256", "ES256K", "EdDSA" ] }, "ldp_vp": { "proof_type": [ "Ed25519Signature2018" ] } } } }vp_token
[ { "format": "vp_jwt", "presentation": "ewogICAgImlzcyI6Imh0dHBzOi8vYm9vay5pdHNvdXJ3ZWIub...IH0=" } ]The simplest request would like this
{ "id_token": { "verifiable_presentations": { "input_descriptors": [ { "schema": { "uri": [ "https://www.w3.org/2018/credentials/examples/v1/IDCardCredential" ] } } ] } } }while more complex request could also utilize submission requirements (e.g. to be able to give alternative requirements).
WDYT?
-
For selective disclosure of claims, I assume proposal would be to use optional
Submssion_requirementspart of PE in section 4.2 of PE spec.Though
Submission_requirementsseem to cover selective disclosure among several VCs and not different claims inside one VC? @Daniel BuchnerI tried to put the PE example that could be an alternative to the usage of “claim" field in section 5 of the current draft, but am not sure:
{ "id_token": { "presentation_definition": { "id": "32f54163-7166-48f1-93d8-ff217bdb0653", "input_descriptors": [ { "id": "given_name", "schema": { "uri": ["https://www.w3.org/2018/credentials/examples/v1/IDCardCredential"] }, "group": ["group A"] }, { "id": "family_name", "schema": { "uri": ["https://www.w3.org/2018/credentials/examples/v1/IDCardCredential"] }, "group": ["group A"] }, { "id": "birthdate", "schema": { "uri": ["https://www.w3.org/2018/credentials/examples/v1/IDCardCredential"] }, "group": ["group A"] } ], "submission_requirements": [ { "rule": "all", "from": "group A" } ] } }Current draft proposes usage of"“claim"“ field in section 5:
{ "id_token":{ "acr":null, "verifiable_presentations":{ "credential_types":[ { "type":"https://www.w3.org/2018/credentials/examples/v1/IDCardCredential", "claims":{ "given_name":null, "family_name":null, "birthdate":null } } ] } } }
-
@Kristina Yasuda I think selective disclosure is defined using the constraints/fields in the input description.
Here is our transformed example from the draft:
{ "id_token": { "verifiable_presentations": { "input_descriptors": [ { "schema": { "uri": [ "https://www.w3.org/2018/credentials/examples/v1/IDCardCredential" ] }, "constraints": { "fields": [ { "path": [ "$.credentialSubject.given_name", "$.credentialSubject.family_name", "$.credentialSubject.birthdate" ] } ] } } ] } } }
-
I have the following questions/remarks/proposals
1. Verifiable Presentation should contain all the required information, what is the added value of encapsulating it into the presentation submission?
Currently, we have: id_token with embedded VP with embedded one or several VCs -- the more layers we add, the more complex will be the payload creation and validation (which also increases the possibility for errors)
Proposal: let's try to simplify the data model as much as possible (without compromising the capabilities and the security)2. Requesting multiple credentials
-
I'm not sure we can cover all cases using a single Verifiable Presentation, namely:
- As a user, I can have multiple DIDs (e.g., all with a high assurance level)
- Different credentials can be issued to different DIDs (e.g., eID is issued to did
123 and my Diploma VA is issued to did:y:321) - When I'm trying to apply to another university, the university would ask to share both, my eID and Diploma VA, for example.
Question: Can we cover this case in a single VP (as a response) – remark: Assume the DIDs can be in different “wallets“ and the keys are non-exportable.
3. The "selective disclosure" part can be reused in 2 cases:
a) when an RP would ask for any credential that with assurance level X and contains the given set of required claims (e.g., name, given_name, nationality)
b) actual selective disclosureI'm not sure how often a VC will be requested "by the schema", like:
"id": "ContosoUniversityCredential", "schema": { "uri": ["https://www.w3.org/2018/credentials/examples/v1/IDCardCredential"] }In most cases the RP would ask for:
- eID, driver's license, Diploma
- eID, diploma, driver's license schema will be different in most countries
VCs today lack a standardized object identifier mechanism, like OID (Object Identifiers). If this would in place, asking for a specific type of credential would have been easy. This may be put in place by different trust frameworks.
4. I put a comment wrt jwt_vp/... in another ticket.
5. How easy/hard is it to maintain, update and use the DIF Presentation Exchange?
We need to keep in mind that RPs will need to define what credentials they request from the users.
What do you think?
-
-
How would the RP define “Diploma”?
-
Every credential, also the diploma verifiable attestation, is defined by a schema. Of course, credentials can be versioned (e.g., EUROPASS is at version 3.1.0) Different versions will have different schemas.
One way to mitigate the issue would be by using a standardized object identifier mechanism, like OID (Object Identifiers). This is not in place.
Another frequently used way is via the type claim:"type": ["VerifiableCredential", "UniversityDegreeCredential"],
The issue is that the types are not standardized (this brings us the OID-like approach) and without good syntax, the number of credential types explodes.The third option would be using a syntax like proposed for the selective disclosure, where RP could specify the set of claims that must be included in the VC. (It is also not ideal).
-
reporter
Torsten:
“First, we don’t need the indirection facilitated by presentation submissions since the RP defines the places where it wants to pick the VPs up in the request.” - yes, because PE was designed to work seamlessly across all envelope/relay layers (OIDC, SIOP, CHAPI, raw VP, etc.). If you throw that out, we’re right back into the developer hell of “Let’s redo all of this across all of these“.
”Second, I don’t know how PE would be supposed to work with the vp_token” - PE is agnostic to all transports, all formats, all envelopes, etc., so I am not sure I understand exactly what you mean.
-
Daniel, PE being able to be used with any transport protocol does not mean interoperability between those protocols - OIDC and CHAPI both using PE does not lead to interop btw OIDC and CHAPI.
If request is being sent using OIDC, response will also be sent using OIDC - OIDC having its own logic for not using presentation submission does not need to need to worry about CHAPI and others using full presentation submission in the response.
-
reporter
@Kristina Yasuda The example I saw under your comment about selective disclosure doesn’t look right - here is what I believe that should look like:
"presentation_definition": { "id": "32f54163-7166-48f1-93d8-ff217bdb0653", "input_descriptors": [ { "id": "32f54163-7166-48f1-93d8-ff217bdb0653", "schema": { "uri": ["https://www.w3.org/2018/credentials/examples/v1/IDCardCredential"] }, "constraints": { "limit_disclosure": "required", "fields": [ { "path": ["$.given_name"] }, { "path": ["$.family_name"] }, { "path": ["$.birthdate"] } ] } } ] }
-
Great, that’s also what Torsten clarified. Thank you both!
-
reporter
“PE being able to be used with any transport protocol does not mean interoperability between those protocols - OIDC and CHAPI both using PE does not lead to interop btw OIDC and CHAPI.” - it doesn’t make those interop at the wrapper layer, but it certainly means that as soon as you crack the objects open that you’re sending across their conduits, you have the same payloads for the actual exchange logic. The actual exchange logic is the majority of the code work, thus having that be reusable and seamlessly replicated across the various envelope transport protocol options is a significant win for the ecosystem. Could we do one-off retreads of the same thing across envelope transport protocols SIOP, DID Comms, CHAPI, W3C, VC Request, raw VP, etc? Sure. Is that a good idea if we can avoid it? No. The entire point of PE is to reduce all now and future envelope transport protocol work to just the envelope differences, while the actual exchange logic inside that describes what is requested/submitted remains the same.
-
I understand the idea. It reminds me a bit of the SOAP protocol, which was designed as being transport agnostic as well. So you can send messages via HTTPS, SMTP and other transport protocols. This abstraction added significant complexity since SOAP could not rely on security, routing and so on provided by the transport. In the end, people used SOAP with HTTPS almost exclusively but had to pay the overhead every time without gaining the (envisioned) benefit. The result: REST replaced SOAP because it is much simpler to use.
My intension is to come up with a as native as possible integration of VPs into OIDC: It shall be as ease to use as possible for developers wanting to use OIDC.
re vp_token - That’s a new token introduced by https://openid.bitbucket.io/connect/openid-connect-4-verifiable-presentations-1_0-00.html#name-new-tokens-extention
I think linking a presentation submission with the content in this token requires a OIDC specific path expression and I’m wondering how this would look like, especially if the vp_token is delivered as a URL request parameter like this
https://client.example.org/cb# id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso& vp_token=...& state=af0ifjsldkjSomething like this?
{ "presentation_submission": { "id": "a30e3b91-fb77-4d22-95fa-871689c322e2", "definition_id": "32f54163-7166-48f1-93d8-ff217bdb0653", "descriptor_map": [ { "id": "32f54163-7166-48f1-93d8-ff217bdb0653", "format": "jwt_vc", "path": "<authentication_response>.vp_tpoken.verifiable_presentations[0].presentation" } ] } }I’m in doubt the
presentation_submissioncan be processed without transport specific code. -
reporter
Torsten: PE and the Presentation Submissions within are agnostic to the curly brace host (OIDC, DID Comm, CHAPI, W3C CCG VC Request, etc.) you place them into. the only thing that changes is the JSON Path you encode into the PE Submission ‘path’ that points to where in the curly brace host (OIDC, DID Comm, CHAPI, W3C CCG VC Request, etc.). The path parameter in Submissions allows you to direct the receiver to the correct object/encoded submission for that entry, regardless of where it resides in the curly brace host, which totally normalizes the processing logic across all curly brace hosts. The PE spec was specifically designed such that you can drop any PE Definition / PE Submission object into the unified PE evaluation functions, regardless of the curly brace host you’re dealing with, and it will process the same way, without requiring you to rewrite any processing logic across curly brace hosts. If you don’t believe it can/does do that, I would love to hop on a call, because that’s the one thing I can assure folks of, given it was the entire point of PE.
-
I have indicated what I see is the problem with PE, viz, mixing up semantics with transfer syntax. PE should simply state WHAT is required and leave the protocol layer to say HOW the VP/VCs should be encoded for transfer.
-
The other way we can simplify things for OIDC is to not directly indicate in the protocol what is required, but to point to a public policy server where the policy is stored, and the policy says what is required. OIDC can then concentrate on the protocol issues of how the VPs should be encoded for transfer back to the RP.
-
To Alen. I see no real value in encoding presentation submissions in the VP, because the VP should already contain all the VCs that have been requested. The RP simply has to check that the correct VCs are present and ensure they match its policy. If VCs are missing then the VP will be rejected. If wrong VCs are included in the VP, the VP will also be rejected. So telling the RP in presentation submission what is present does not really help, since it could be wrong, and even if it is correct, the RP will still need to check the VCs to ensure they are correct. It is complicated overkill in my opinion
-
reporter
“PE should simply state WHAT is required and leave the protocol layer to say HOW the VP/VCs should be encoded for transfer” - I would love clarity on what exactly you mean by this. PE doesn’t do this, to my knowledge, it simply requires that you stick in an object that describes what you are sending back (e.g the format) and where in the curly brace host (OIDC, DID Comm, CHAPI, W3C CCG VC Request, etc.) response object that the thing lives.
-
reporter
“I see no real value in encoding presentation submissions in the VP, because the VP should already contain all the VCs that have been requested. The RP simply has to check that the correct VCs are present and ensure they match its policy.” - I don’t think this is accurate, because in scenarios where you are presenting the Holder with multiple choice options (as you can with Presentation Exchange Submission Requirements: DIF Presentation Exchange (identity.foundation) - click on the Single Group Example tab), you really need to be sending back mapping info to inform the Verifier of what selections you’ve made relative to their definition’s rules.
-
Daniel, if the holder is able to process the various options and determine which VCs to send to match one of them, then the same process can be undertaken by the RP to check that what the holder sent is correct and matches at least one of its options. If the RP is not capable of doing this (with all its potential processing power compared to that of a smartphone) then how do you expect the holder to?
-
Daniel “it simply requires that you stick in an object that describes what you are sending back (e.g the format)”. WHAT you are sending back is a W3C VC that can be in multiple different formats according to the W3C Recommendation. The protocol will specify which format it requires you to use. Some protocols may demand DIDs for subject IDs, others may demand JWT encodings for VPs and VCs and not ZKPs. The format of the VP is the domain of the protocol, not of the request, which should concentrate on the semantics.
-
Daniel “where in the curly brace host (OIDC, DID Comm, CHAPI, W3C CCG VC Request, etc.)” This confirms my point. These are protocol issues. OIDC should say nothing about DID Comm and does not know anything about it. Therefore there should be no possibility for DID Comm to appear in an OIDC protocol.
-
reporter
“If the holder is able to process the various options and determine which VCs to send to match one of them, then the same process can be undertaken by the RP to check that what the holder sent is correct and matches at least one of its options.” - In a world of credentials, we will start seeing combinatoric selection optionality that we don’t really see today with more direct/siloed centralized and federated identity systems. Because the natural world of credentials often presents multi-part optionality, why would we want to shoulder a verifier with spinning needless CPU cycles running the submitted creds through N different combinatoric formulations to determine satisfaction, when you could have the Holder indicate the option formulation they are submitting against? The bytes required to do this are minimal, and the gains in standardization of the combinatoric selection/submission are significant. I suppose this brings up the more general question: are folks here even considering use cases involving selection optionality? If not, you should, because multiple issuing/verifying organizations have already deployed solutions utilizing these features (including one government).
-
I have not yet seen a good use case for providing optional credentials. And this breaks GDPR minimal disclosure principles. So I am yet to be convinced of the value of optionally providing more information than is required
-
reporter
David: I am not talking about selection options, as in, you do or don’t need to submit something, I am talking about selection optionality in the sense that you may present a multiple choice requirement as follows: “To do Action X, submit 1 of either A or B credentials, and 1 from C or D credentials“. It’s a combinatoric selection between multiple things that can fulfill a requirement, not the idea that you’re needlessly sending random things you don’t have to. We are seeing multiple groups implement these selection scenarios, and they asked for this capability to support them.
-
Daniel. Then we are talking about the same thing. We have already implemented exactly this disjunctive form of request and have no need to return presentation submissions. Our verifier has no difficulty in matching the VCs in the VP to the original policy
-
- changed component to Verifiable Presentation
- edited description
-
reporter
David: there are many cases, which we are already seeing (and that some parties have in active deployments), where Verifiers would like to present an offer to verify/issue based on fulfillment of conditions with sets of options. You keep talking about how you’ve done this, yet I see no standard means for doing this in any of the specs. Are you talking about a custom policy expression/evaluation you are doing yourself, vs a standard syntax to present the wallet with option sets where one-from-N will meet the conditions for access/issuance? If you are asserting that such a standard for combinatoric expression syntax exists, please cite the applicable OIDC standard text in your very next reply.
-
Daniel. I am making two separate and independent points
i) The way the requirements policy is expressed could be by publishing the policy in a public repository (one of the Verifiable Data Registries from the W3C recommendation, much like @contexts are published) and sending a pointer to the policy in the protocol rather than transferring the entire policy in the protocol, (note this is independent of how the policy is specified) and
ii) I see no need for the VP to include a presentation submission object inside itself, since the VCs alone are sufficient for the verifier to know if the policy has been fulfilled or not. One could consider including a pointer to the policy in the VP if one does not want the RP to keep state information linking the VP response to the request, but I think OIDC already requires the RP to keep this state information (and to recognise the challenge), so I am not suggesting including a pointer to the policy in the VP.
-
- changed status to open
-
-
@Daniel propose to close this as PR #20 has been merged.
further enhancements to PE in OIDC4VP should be filed as separate issues.
-
reporter
@Kristina thank you and @Torsten for helping to get this in. I took a look at the PR and noticed a couple things (which I can note elsewhere if more appropriate):
- I see that the PE Definition lives under the
verifiable_presentationsproperty - is this a required deviation from the spec, or can this be located under a prop namedpresentation_definition? I ask because the spec directs implementers to look for that prop. We could change this in the PE spec, but for devs it might be nicer to have it always appear under the same prop name, for normalization/consistency sake. - The
schemaprop in the PR examples looks to be an object with auriproperty, vs an array with objects as entries that haveuriproperties. I know that this was a simplification that @Tobias proposed, which folks in the DIF WG were amenable to, but wanted to make sure that deviation from the (current) v1 PE spec was intentional. If it wasn’t we should probably stick to the v1 spec, but if it was, we should all try to align the PE spec to that simplified property value format that @Tobias proposed. How can I best close on this with folks here? Can we do a joint OIDC/DIF call to iron these proposed changes out? - The
formatdeclarations appear to be outside of the PE Definition object, under avp_formatsproperty, but does look like it shares the same format/alg/proof type syntax now. Per the current spec, that prop should reside in thepresentation_definitionobject itself, under a prop namedformat. Is this something folks would be willing to take a PR to adjust for interop sake? I just want to make sure it remains compatible with the libraries that will be looking for theformatvalues in the specified place/prop it usually is found.
- I see that the PE Definition lives under the
-
Account Deactivated
On 1. I would also prefer to use the PE spec property name of
presentation_definitionso that it clearly identifies what to expect as the value of that property, and keep theverifiable_presentationsas the property name for what is returned in avp_tokenas that clearly associates it with that property’s value as defined in the OIDC4VP draft.On 2. has there been discussion on how to handle versioning between the specs? This seems like a good case/time to work that out, that ODIC4VP needs the ability to specify which PE version the included
presentation_definitionis, which may be external to the property or in metadata, or also detectable within that property’s value.On 3. I missed the discussion on this so my thoughts might be late, but based on the updated verbiage in the updated OIDC4VP draft I believe there’s a desire for the OIDC metadata to support and serve as method by which both parties determine what formats are supported between them. I would go a step further and greatly desire for the entire
presentation_definitionto be able to be included in the metadata, and only referenced by it’s uniqueidwhen included in a OIDC4VP presentation request. This supports a trust framework architecture where the presentation definitions are commonly defined and agreed to amongst multiple parties. -
Jeremie. On 3, my preferred model is somewhat similar to yours, but instead of metadata, I prefer that presentation requirements (or policies - which can be in any language, not just PE) should be stored in a publicly accessible policy registry that the ICO can inspect and that multiple RPs can use. Eg. all nightclubs can reference the Over 18 policy, and the user’s wallet will fetch the policy from there.
-
Account Deactivated
but instead of metadata, I prefer that presentation requirements (or policies - which can be in any language, not just PE) should be stored in a publicly accessible policy registry
I think we’re agreeing on the intent of having a way for it to be externalized, I’m probably just using the different language of a “trust framework” that I believe could also be defined as a policy registry.
that the ICO can inspect
I’m not familiar with this term and google wasn’t helpful, maybe I’m missing an obvious expansion of the acronym
-
Sorry, ICO=Information Commissioner’s Office. Eg. see https://ico.org.uk/
-
- changed status to resolved
Closed during the 15-Jun-21 call, since PR #20 accomplishes this. If people want to file individual issues about the details of how it is used, they can do so.
- Log in to comment
- Assignee
- –
- Type
- Priority
- Status
- resolved
- Component
- Verifiable Presentation
- Milestone
- –
- Version
- –
- Votes
- 1
- Watchers
- 12
Can you please point out exactly which proposals, issues and spec details you are referring to?
Apart from how to name the JWT claims to include VPs (vp_jwt, vp_ldp), which we are not using for now, I cannot recall any.