On 8/17/2021 12:14 AM, David Chadwick wrote:
On 16/08/2021 22:16, Joe Andrieu wrote:
Based on conversations with the use case team, I've put together the attached diagrams, illustrating a minimum conceptual model based on the USCIS Green Card use case, as implemented using CHAPI.
I'm sure this model is lacking some elements for folks who have a slightly different configuration. I chose this use case because it is the one I'm most familiar with, making it easiest to be complete. I'd like to speak to folks with different scenarios and see if we can't come up with a variation that covers your requirements....
6. The message names are chosen for logical consistency in "normal English"; they should likely be turned into camel case or something and we can have a bikeshed festival....
Thanks for these. Overall they are in the right direction. Here is my feedback.
1. On the issuer
This is too specific (i.e. not generic enough) as it requires the holder to present a VP in order to get a VC. But what if the holder does not have any VC to turn into a VP? Can you generalise it by having a challenge and a signed challenge (or authentication response) and verification of the response without mandating this to be a VP?
Can't a VP be signed without any VCs inside? What is the specification status of an empty VP? As far as I can tell, a VP with no VCs in it is a fairly common mechanism for signing a challenge to authenticate control of a DID, although to be honest I'm not really clear on whether there is an equivalent for "linked-secret"/indirected-identifier subject credentials (i.e. Indy or Azure) or for non-DID VCs.
Yes you could use an empty VP to show control of a public key, rather like a PKCS#10 message.
David, could I ask you to describe a little what the challenge/AuthN flow is like in your system and where the sticking points would be in rearranging it a bit to conform to an "empty VP" style flow? Would it be generalising enough to rename the VC-request to a "provide challenge" (with optional VC request in tow) and to rename the VC selection "Prompt for consent (and optional VC selection)", or did you have a further generalisation in mind?
I had further generalisation in mind as described below.
The information flow in our system starts (according to your
flow) with the user consenting to the holder requesting a VC, then
the holder establishes a TLS connection to the issuer, the issuer
sends a FIDO authentication challenge, the holder responds with a
signed FIDO authentication response and a self signed ephemeral
key and the issuer provides the VC to the ephemeral public key.
(But in our flow there is an initial registration step that is not
described in your flow, during which the FIDO key pair is
established between the holder the issuer.)
So the flows are very similar, but the messages that are sent in your flow chart to make it more general are:
o) Issuer service (holder) should be renamed to Crypto Service
i) 2. "Authentication challenge"
ii) remove messages 3 and 4 (not needed) or make optional
iii) 5. "Create response"
iv) 6. "Sign response"
v) 7. "Signed response"
vi) 8. "Signed challenge/response"
vii) 9. "Verify response" (Verifier Service should be relabelled "Crypto service")
viii) 12. is optional
2. On the verifier
There is some confusion in the numbering from 14 onwards. 15 should come before 14 and 17 and 18 are not needed. Otherwise this seems OK.
On Sun, Aug 15, 2021, at 4:41 PM, Manu Sporny wrote:
VC HTTP API Work Item - August 17th 2021
Time: Tue 4pm ET, 1pm PT, 10pm CET, 8am NZDT (Wed)
Duration: 60 minutes
MEETING MODERATOR: Manu Sporny
1. Agenda Review, Introductions (5 minutes)
2. VC HTTP API Renaming Poll Reminder (5 minutes)
3. Simple Majority Objection w/ GNAP-KBAT (30 minutes)
4. Feature Scoping (15 minutes)
5. Pull Requests (5 minutes)
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
Joe Andrieu, PMP email@example.com
LEGENDARY REQUIREMENTS +1(805)705-8651
Do what matters. http://legreq.com