# Notes: Joint PE/OIDC conversation

# Key Links to Specifications
[OIDC4VP](https://openid.bitbucket.io/connect/openid-connect-4-verifiable-presentations-1_0)
[DIDComm](https://identity.foundation/didcomm-messaging/spec/)
[Presentation Exchange (aka PE or Pex)](https://identity.foundation/presentation-exchange/spec/v1.0.0)

# 4 Aug

Agenda:
-
-

# July "homework"

See "## next steps" under 7 July

# 7 July

## Attending

Pam Dingle, Jeremie Miller, Brent Zundel, Daniel Buchner, Daniel McGrogan, Juan Caballero, Michael Jones, Oliver Terbu, Tobias Looker, Brian Richer, Alen Horvat, Kristina Yasuda

## Discussion
* Oliver - looking at presentation exchange as a function where certain inputs are supplied but it doesn't matter where in the envelope we get those inputs, this could be one way to move forward
* How could we evolve PE to be more "native protocol" friendly in the next version?

* Kristina: several ideas were brought forward
* "modularity" was the key word
* need to agree on direction

Goals:
* With respect to PE 1.0
* a PE definition function expecting parameters
* can OIDC define how to reassemble a submission object even if there isn't one?
* examine each OIDC object in the array
* submission doesn't contain the values today in OIDC but PE does
* format - is ok
* path - should be able to happen
* Oliver: assuming OIDC4VP has already landed on using PE, does this process for encoding a PE object - is that part of OIDC4VP?
* Alen - it depends whether in PE it is acceptable to refactor current data model
* if not, OIDC would need to specify how to assemble such information
* if so, OIDC would not need to define anything extra
* To consider: perspective of other protocols

* Kristina - in OIDC4VP the consensus was that some changes in language would be important if possible in PE1.
* needs to clarify which module/component syntax boundaries are
* Oliver: Need transformation rules in OIDC4VP for use with PE
* Tobias: PE would define here is input descriptor/format definitions in the sub-data-models. DIDcomm (and other protocols) would define use within its context.
* Kristina: already some issues in the DIF PE github, those issues can drive the overall shape of what has to be defined
* language on schema
* Tobias: two suggested batches of changes
* reorganization - ability to pick/choose what gets used where
* terminology/structure - this would be a breaking change
* eg revisiting "schema"
* Oliver: even if a 2.0 is agreed on, what is required for progress?
* Daniel:
* In OIDC4 VP:
* Breaking: on the Submission side, add the ids for the objects
* PE can define a property that is standardized for an identifier for the presentation
* SIOP adds a new prop containing the different creds containing an array (this likely vp_token)

Summary:
- PE would not define the entire presentation submission, just those things that need to go into the response
- OIDC4VP would define the id tags needed to map

Oliver: need mapping for transformation functions, shouldn't matter if OIDC4VP uses different stuff, as long as there is a deterministic algorigthm to transform

Check with PE editors: proposal seems reasonable for a 1.1
Check with OIDC4VP editors:
next steps are
- add language to PE about module-approach
(this would solve the format issue)
- add language on submission (both PE and OIDC4VP)
- address syntax issues (type, etc.)

Oliver: is it acceptable that there is a strong link between PE 1.1 & OIDC4VP (Oliver is ok, but worries about others)

Alen: need to be sure this doesn't hobble the spec too much - goal should be to preserve loose coupling in case other syntaxes come up in the future

Kristina: perspective is understood, but counter-proposal would be that more flexibility could mean more confusion. Current direction of modularity lets PE be useable from OIDC4V even in later versions.

Daniel: assumption of reliance is ok

## Next Steps:
PE: Daniel proposes one monster session for a 1.1 draft (with minimal changeset)
* Alen: both sides could take the examples that Torsten made and use that as a starting point
* can these be the canonical examples?

* Mike: we need to run this past Torsten
* Pam: shall we make working groups on both sides aware?
* Question on IP: some calls are IP-protected, so

Kristina: DIF is the most likely home for any joint calls due to IP reasons
* Mike: any attempt to create joint assets is probably not a good idea

Daniel: assuming an initial ok from Torsten, the PE group could set up the proposed changes so that an August meeting could review as a next step

Current plan: new meeting in August 4 same time.

# June 30 notes

## Levelset

## OIDC 4 VP

Tobias, Torsten, Kristina all here representing
* Implementers use the OpenID Connect core protocol for all the negotiation, at multiple layers
* Editors revisited presentation exchange – has unique value for complex use cases
* Eg: requests for alternative credentials
* Design goal: someone familiar with OpenID connect can be familiar but also embrace hybrid use cases

The OIDC4VP spec has two main deviations from PE
1) Does not use presentation submission – it uses an artifact “vp token”’
* Today the presentation submission refers to a single JSON object
* In OIDC, different artifacts are negotiated over possibly different channels
* Also a userinfo endpoint breaks claims out of tokens altogether
* RP is in full control of request format, presentation and where the cred/token goes
2) Does not use format element
* Client/OP set up relationship in advance (ie dynamic client registration or proprietary app registration)
* Signing algorithms are part of client metadata – same data is defined but in different place
* It is an advantage to know the algorithms before the negotiation needs to take place

## DIDcomm

Stephen Curran representing with additional comments from Daniel B

DIDcomm works in the following way:
* DID Comms provides a means for two parties to connect
* PE doesn't assume how parties connect
* Verifier has a request for a verifiable presentation
* Prover selects credential, sends claims ideally in single message
* Protocol can use different formats for presentation request & presentation
* DIDcomm itself works across all transports
* An issuer will give a holder a credential in a certain format – that format is propogated to the verifier without any ability to transform
* Stateless transfer of message is key

# Comments
* Points made by Torsten
Torsten did a great job summarizing two relevant features of OpenID Connect:
(1) There are multiple locations that claims are returned and which locations are used should be under the control of the RP.
(2) There's an existing widely-used metadata publication mechanism and any natural integration of PE into OpenID Connect will use that mechanism to publish presentation metadata.

* feedback from Alen
DIDcomm – 2 parties establish a message, and this process is well defined
OIDC – 2 parties negotiate metadata
If PE was made more modular, there is room to use this within DIDcomm (more modular may make this more flexible)
Both presentations and credentials can exist with different formats (any combination of JSON, JSON-LD, even XML)
Interoperability here is a different question
Type/format of processible creds are needed often in advance
Deterministic signing validation is an open topic (I hope I summarized that properly)
Can PE exchange data on format of both credential & presentation?
* Tobias:
* Daniel:

Four possible options
1. Just use PE as is, no changes other than picking where the two objects go.
2. Switch modes between "PE Strict" and "OIDC Default"
3. "nuclear option": make remove PE refs from SIOP, and PE will define a SIOP embed target profile inside itself.
4. Decomposition and recomposition: allows more envelopes but adds more cruft (and risk of confusion) to each envelope.

* Justin Richer:
* Instead of more modularity, is it really different modularity?
* Nature of combining systems means there are different lense
* Possible framing question – what does the resulting conversation more naturally look like?
* This could define where the line is drawn for abstraction/modularity

* David Waite:
* If a protocol wants to have different ways of definition, they can do that - rather than modularity changes there could be enhancements
* Other folks using PE could adopt the enhancements
* Allows for the statement "you need to get PEX data into this layer somehow"

* Torsten:
* "transport" discussion last occured in SOAP/XML
* SOAP discussion was end-of-lifed because it created a lot of overhead
* Could PE be a toolbox of useful syntax that can be built into protocols in a native way?
* Question: what is the status of implementation experience across PE

* Lio:
* has been implementing OIDC and SIOP and others
* underused in OIDC is the aggregated and distributed claims portion of the spec (only defines "JWT") - Workday has extended in this way and have found it very useful
* userinfo endpoint is supported by many off-the-shelf OIDC client libs
* could be a natural extension point to add PE like data in the response
* another positive: the flattened view of userinfo is very useful, still keeps the cryptographic proofs around

* Daniel:
* PE is like HTML - is a document with a different format
* you can augment it
* desire in OIDC is not necesarily to keep PE as a standalone document
* goal is deterministic mechanism, not about where they live but how can the librarily always
* Mike Jones:
* Having to reshuffle outputs rather than putting them directly in the right places would make extra work for everyone

## Next Steps
* Group agreed to meet again next week
* Discussion: what is the evolution of PE?
* Goal: circulate the options in advance