Notes from "What does Presentation Exchange do and what parts of it do we need?" IIW session, 12-Oct-23

Adrian Gropper: What is the flow used by Presentation Exchange?
	Brent Zundel: The context for the request is known to the requester and is not part of PE itself
	As a verifier, I need a way to ask for information

Paul Bastian: Brent, as an author, what do you think was good and what wasn't
	Brent: We've received feedback from OpenID people in the past
	We're working on a 2.1 version

David Turner: The BC folks see multiple requests as being a bad thing

Adrian asked about the context of the interaction
	Brent: The application understands the context

Sam Goto: We struggle with that question as well
	It creates a lot of complexity
	A lot of that complexity can be handled by the verifier itself

George Fletcher: As a verifier, I have zero idea what wallets I'm using and what credentials they have
	It isn't the user choosing - it's the verifier saying that I need this set of data
	Sam: The complexity comes from asking for multiple things in one package
	George: Want to reach the maximum number of people

Torsten Lodderstedt: I've been implementing PE
	I would love to be able to combine credentials
	But there's not enough context to know how to do that
	For instance, you want to be able to say that the names in multiple credentials provided need to match
	A principle I like is that there is no transformation
	The input descriptor is specific to a particular format
	There are differences in claim names for mDOC and JWT and SD-JWT
	There are different kinds of credentials and different formats
	I don't like the complexity but it solves real use cases

Sam: Can we agree on the 10 most important use cases?
	Then we can debate whether its overly expressive or underly expressive
	Torsten: I can show you my code
	You need to be able to receive credentials in different formats

Brent: In defense of PE's complexity - it's there to enable complex use cases
	The goal from PE 1 to PE 2 was to enable incremental deployment of features
	We're happy to take feedback and incorporate it in 2.1
	We want this to be usable for people actually trying to use it

Mike Jones: One ideas is to enable the verifier requesting a sequence of credentials
	You still want the user experience to be good
	For instance, there may be a way to have the verifier sign into the wallet once
		and make future requests without signing in again

Torsten: What you're describing sounds dangerous
	HAIP limits the PE syntax used
		Cannot request concatenation
	Inventing a silent login to the wallet sounds like a bad idea

Paul: I agree that the obvious choice for eliminating the complexity is removing the "and"
	There might be use cases where the second credential you need depends upon the contents of the first credential returned
	It may fit better with the credential selector approach

Mark Dobrinic: For minimum disclosure, asking for one thing at a time may be better

Brent: There are multiple complexities in PE
	One is constructing the query
	A wallet that just speaks PE doesn't have to care
	If it understands PE, it doesn't have to care
	The things returned would align with the needs of the verifier

Torsten: How many people in the room have implemented all of PE?
	Brent: I think Gen Digital's engineers have
	Torsten: I think we need real feedback from developers
	I think that it is impossible to have relationships between credentials
	Paul: Talked about use case with a diploma and a national ID card

Sam: Verifiers have languages that are Turing Complete
	You can do loops, ifs, etc.
	PE will never be as expressive as JavaScript
	By analogy, the Web browser doesn't give you a file picker with a SQL query as input
	So much of the complexity of PE presupposes that the communication with the Wallet is expensive
	Brent: We didn't assume complexity of communication
	We assumed that things that are being requested together are related
	... Birth certificate, etc.
	Sam: You could do a sequence of queries - starting with "Name from Birth Certificate"
		Then name matching could happen in the application
	Brent: The beauty of PE is that you can use it as simply as you want
	Sam: You can decompose PE into smaller units
	Brent: There are use cases that call for the bundling
	Sam: Those can be decomposed into a sequence of requests

Pedro Felix: Related to this, there is also consent by the user
	Some things I'm comfortable releasing - some I'm not
	As a user, I'd like to know everything being requested up front
		Like when opening a bank account
	That enables me to make a cost/benefit decision
	Mike: It can be hard to create a comprehensible user experience for multiple-choice requests

Nader Helmy: If the complexity is so high that people will implement it incorrectly, that's a problem
	Or is the complexity doable, with the end result being a better human experience, then it's not a problem

???: We can't completely separate the UX issues from the protocol issues
	Doing things one-by-one is different than multiple
	Paul: If you're in the cross-device flow and you have to scan the QR code multiple times, that's a problem

Iain Corby: We operate an age verification system in the UK
	We found that requesting multiple credentials at once was a must

???: We've implemented PE
	Having the "and" is valuable for us

Brent: In some protocols, simpler flows make sense
	If that's 99% of the use cases, we'll trim it down
	A design goal was being transport agnostic

Jacob Ideskog: On the verifier side, the PE query may be static
	The negotiation protocol described may actually be more complicated
	Mike: If you have a complex query, you likely have complex code in the verifier to understand the response