Eric Schuh: Document we are referencing page 34 - start of revision getting into github is goal. ✪
Eric Schuh: We want to talk about the abstract sections - terms issuer role terms service ✪
Eric Schuh: We tried to get a high level scope on the various APIs - one challenge with the use-cases not having a well defined scope and where the gaps are in the use-case. ✪
Joe Andrieu: We had touched on this before - the party calling the verifier API not the verifier. we used role because that is in the spec. ✪
Joe Andrieu: I think we have convergence - on issuer and verifier aPI ✪
Joe Andrieu: Issuer role how it talks to Issuer service. ✪
Juan Caballero: Note: one pages 4-6, we have the diagrams of how these three "roles" map to various components and services ✪
<bumblefudge> on*
<bumblefudge> s/one/on/*
Joe Andrieu: How the issuer role/service interacts with the holder's wallet - or the software that is particiapting as wallet (CHAPI/DIDComm right now). ✪
Joe Andrieu: Question what is out of scope. Role issuer talking to verifier - not a thing. ✪
Joe Andrieu: One caviate one verifier service talking to issuer service - may encompas status-check mechanism. While we don't want to put in the phone home mechanism - here is the privacy respecting way to have that use-case met. Kinda the issuer talking to verifer - as long as done indirectly. ✪
Juan Caballero: Only add that the terminal logical moras - I've been following. Holder-holder service-holder finding a hard time finding common ground I hope you find this. ✪
Manu Sporny: Clarifying question - what questions do you have for the group. ✪
Eric Schuh: One that came up - speaking to holder-holder interaction ok to be modeled - recipient holder - and reciving a verification from the sending holder. ✪
Michael Herman: Bound credentials - unbound credentials (no subject ID) both valid in VC spec. Michael is interested in unbound credentails - invoices and purchase orders. complex documetns are not just extension of subject. ✪
<orie> no juan, unbound credentials don't have a subject identifier.
Michael differnet protocols for bound vs. unbound ✪
<bumblefudge> thx orie
<davidc> @identitywoman. "When we are using the OIDC Protocol to pass a VP from a holder (and this has been defined now in the draft extension) then the recipient is the RP, and the RP will call the Verifier API
Justin Richer: There are a few ways that this family of APIs can plug in - who is going to be issuer or holder or veriifer or IdP and RP etc. not to contradict what David was saying - one of a number of different dimensions. how do you overlay these things with each other. ✪
Orie Steele: +1 To what Justin is saying, VC-HTTP-API ... OIDC can be configured differently per use case / requirements ✪
<justin_richer> requesting party is not relying party! This is long established in the UMA space. (but naming is hard)
<eric_schuh> "Requesting" implies that that role will always be the initiator and I don't think that is the case in many verification use cases. Is "Recipient" a better term?
Manu Sporny: In the VC spec we call this thing a requesting party - client is acting in a role and server is acting in a role.. useful to think of it in that way. I take ted's concern if you are recieivng something and not verifiying you are not a verifier. ✪
<justin_richer> and "relying party" is a very specific term from the IDAM space
<orie> presentation "sender" and "receiver"
Manu Sporny: What kind of concrete decision was use-case team hoping to make. ✪
Eric Schuh: The verifier role weather it becomes requesting recipient reciever. we went with it (but didn't like it) but went cause it went with the way the VC community does. ✪
<orie> I agree that the word "verifier" is problematic... if the verifier can store or not store, or verify or not verify
Eric Schuh: Can we get consesnsu of in scope vs. out of scope - under different api - issuer role to issuer software is in scope. ✪
<orie> currently there is no way for a "verifieir" to "request a presentation"
<bumblefudge> maybe i'm being reductive, but if they store, they are a verifier-holder; if they don't, they're just a verifier; if they're not verifying, are they even conforming to this spec?
<orie> there is a way for a "holder to submit a presentation to a verifier/holder"
Eric Schuh: More time to drill into use-cases that we are missing. we have some gaps in currently accepted usecases. they don't cover all teh interactions. but hard to tell we don't know what the scope is ✪
<bumblefudge> yes, scope proposals on CCG list using these terms and the diagrams on pages 4-6 would be VERY HELPFUL. scope proposals NOT doing so would be NOT very helpful
Manu Sporny: Orie i will make sure he interprets what I'm talking about correctly. ✪
Manu Sporny: Raise this PR with resolutions we have made so far. ✪
Manu Sporny: 224 Rather then leaving it blank - working group needs to write stuff to move resoultions into spec so things can go in a certain direction. ✪
Manu Sporny: Feeback or concerns. spec editing perspective. putting things like this inside spec-tec vs an issue tracker - not as useful as it migth seem that said nothing specifically prohibitive of somethign like this ✪
Joe Andrieu: Question is this PR the right place to challenge the resolution that happened in the session that was a majority decision. would like some other group review it. Things being recorded as consensus resolution- free to raise concerns/issues. ✪
<justin_richer> "consensus" needs to be robust against some number of -1's to survive
((Consensus by the faciltiator definition - means everyone agrees)) ✪
Joe Andrieu: I am going to raise objections in the issues ✪
Joe Andrieu: It was a can of worms and I'm upset about it being railroaded through - in appropriate and unfortuate. ✪
Brent Zundel: Comments on process may apply on working group and what process those chairs have established - can those be applied to work item or community working gorup - looking at work item document this doesn't apply to ✪
<brent> that was my point exactly, thank you Joe
Joe Andrieu: I wrote the current charter - standard for consensus - principled objections - manu is not chair moderating these meetings. WE don't have a formal process we are operating processless. ✪
Manu Sporny: You know how to do this make a concrete proposal ✪
Why do we believe the issuer retains a copy of all issued credentials. ✪
Orie Steele: Current APIs don't assume statefulness ✪
Manu Sporny: Maybe there is no assuption - they retain a copy. ✪
Manu Sporny: Revocation lists imply status in issuer API ✪
<orie> ^ imply "statefulness and persistance"
David I. Lehn: You are saying you are making no assuptoins but in terms of the API you are making implicit assuptoins about what it can do. You are making implicit assuptoins that are not documented. ✪
<orie> lost audio
Michael Herman: Part of this process is mimicing real life - provicne issuing DL or country issuing passport. ✪
Michael Herman: They do keep a copy - they have copies of them or ability to re-generate. ✪
Orie Steele: +1 To discussing "recommendations for retention, statefulness, and persistance" ✪
Michael Herman: It is assumed it will retain information for it to maintain API - when maintaining revocation lists it will ✪
<orie> it is a much longer discussion
Michael Herman: We don't need to link with the revocation list api ✪
Orie Steele: Reading what we have today it is undefined behavior - cases where you would like it to be defined positively from a negative perspective or positive perspective. ✪
Orie Steele: Both valid use-cases it is undefined behavior today - we are planning to define some of that behavior. ✪
I heard concern about the issue being defined in a way for honey pot of credentails. ✪
Orie Steele: I don't think we are planning on defining that behavior. ✪
<orie> for example, our prototype that passes all the tests, does not support persistance at all.