[MINUTES] VC API Work Item Telecon 2021-10-05

Thank to Orie Steele for scribing on the 2021-10-05 VC API work item call. W3C
IRC servers were down (which we use to run the bots)... however, the W3C CCG
infrastructure survived the outage and the group did their best to ensure that
the meeting was recorded. Minutes below...

# CCG - VC API - 05 Oct 2021

NOTE: Due to W3C service downtime, we used a HackMD at
https://hackmd.io/x4wsZ7kwR66H9kq4EFceow for scribing.

## Organizer
Markus Sabadello

## Scribe

Orie Steele

## Participants
- Markus Sabadello
- Ted Thibodeau
- Joe Andrieu
- Justin Richer
- Mike Varley
- Dmitri Zagidulin
- David Chadwick
- Orie Steele (scribe)
- Brent Shambaugh
- Adrian Gropper
- mprorock

## Agenda

### Topic (time)
1. Agenda Review, Introductions (5 minutes)
2. Issue Processing (55 minutes)
   *
<https://github.com/w3c-ccg/vc-http-api/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc>

## Minutes

### Agenda Review, Introductions

(take notes here)

### Issue Processing

(take notes here)

Markus: how shall we handle Q?
... if you want to Q, add yourself to hack md Q section.
... looks like we are ready to go.

Agenda: Issue Processing

Markus: We have 84 open issues.
... anyone want to introduce themselves?
... ... ok issue processing.

... Lets look at oldest issues first.
... is https://github.com/w3c-ccg/vc-http-api/issues/50
... I created this, to discuss didccomm / client server, etc...
... seems related to WACI, etc...
Mike: seems like we have addressed this in WACI, and its stale.

Joe: we seem to have agreement to implement an http api.
... there are choices we could make that might make it harder to switch
transports.
Orie: When you define an API, you can define an operation name, which can be made
... available over other endpoints; there may be e.g. message-oriented
architectures using WebSocket

Mike: basically what Orie said... we do need a way to define interfaces... we
seem to have that.
... we should be thinking about this independant of transports.

Markus: seems like we might want to note something about operations over other
transports.
... we should add a comment and ask to close it.... please add comments to
issues as we go.

... Jumping to  https://github.com/w3c-ccg/vc-http-api/issues/53 and
https://github.com/w3c-ccg/vc-http-api/issues/54
... I think they are related... who talks to who?... David are these issuse
still relevant?

Joe: I'm on the Q...

... maybe I can be assigned? we've made sequence diagrams... hoping to get
them validated...

Markus: we already have a diagram... David, we can't hear you.

David: this issue can be closed.

Joe: can we leave one open as a place holder for a PR.

Markus: yes.

... lets look at  https://github.com/w3c-ccg/vc-http-api/issues/52
... allow setting status before issuance.
... seems related to status changes...
... should it be possible to change status of a credential before it is issued.
... then discussion of didcomm...
... do we want to explore pending / pre-registered credentials?

Joe: not sure, but this feels like a race condition... between status and
issuance.

... not sure, this impacts state... feels weird to me that a VC would be in
that state.


Orie: Agree with Joe. Today if you want to issue a VC with a revocation
status, you need to consume a status list index, craft a payload, and then get
the credential issued.

... And then you can change the status, but you can only do that after you
have a credential ID.
... There are other problems with describing credential status.
... It feels wrong to change the status of something before it has been issued.

Joe: we have not looked at issuance, we seem to need to look at flows related
to issuance... there is ordering here...
... the status check vc must be created first.

Markus: David wrote that it seems wrong to publish the status of non existent
things...

Dmitry: I don't understand "pre-issuance status"... publishing the status of
things before creating them is common in key value systems.
... status does not matter until issuance.

Markus: what do we do?... with the issue.

Mike: seems like maybe this issue is not valid... maybe we can ask the issue
participants to help?
... unless a use case emerges for it, it should be closed.

Markus: I don't remember folks talking about this recently.

Dimitry: David said, it does not matter if credential is issued before status,
it won't matter...
... is checking for verification part of  verified... should credentials with
broken links be valid? ... seems like a no.

Orie: it's a failure today, in the test suite.

Joe: seems to be odd that it would be a failure... I understood revocation to
be a "deny list"... seems valid unless its revoked.

Dimitry: the behavior depends on the revocation list type... so it depends....
its spec detail, based on type.

Markus: do we want to keep this open?... if the verifier can't...

Joe: If you can't get the list, assume its revoked... seems like we need to
document that.

Orie: Agree with Joe, revocation needs to be documented signficantly better,
or removed from API. These questions should be clearly answerable.

... If the API exposes revocation capabilities (debatable if we do that well
enough), then we have a lot of work to do to get to interoperability.

Adrian: one of the things I am strongly advocating for, is that the VC API
apply just as much to the issuer as the holder... in other words, whatever
authorization mechanism exists is the same... seems potentially useful to not
worry about revocation.

Markus: please add a note to the issue.

... lets look at 55, 56, 57... they all ask questions about the verification
process.

... 55 is about what steps a verifier performs... checking the signature, but
what about they other stuff?
... does the verifier validate "business rules".

... then there is issue 56... can you send the proof request associated with
the credential?... then the verifier could check too make sure that VC1 is not
presented for VC2 request.

... issue 57, align the verifier API with DIF PE Spec....does the verifier
enable specifying a presentation format?

Joe: I think we would do well to follow the distinction the VC spec does...
and leave validation to the App..
... business rules that the verifier role are business specific on a claim by
claim basis... ie, i accept dmv for age.
... seems like we can't handle this, and the app exist to execute these rules.

Markus: verification and validation are in the vc data model?... you are
suggesting validation is out of scope

Mike: I agree with joe, we had a similar question about how to construct a
VC.... seems like this API is pretty basic, and validation is out of scope.

Markus: <inaudible/>... thoughts on this?
... I also agree with joe... one comment, there is a 4th issue... 62...
document check algorithms in spec... we need to define the checks.
... the test suite sends options when testing a verifier endpoint... most of
the time its just the proof... but also credentialStatus.
... does that change this discussion?

Joe: seems bad that its variable... seems like a footgun.

Orie: I didn't come up with that part though. I'm also frustrated with the
variable nature (of the current mechanism). In our implementation of the test,
we have to look at the options, and basically lie, wrt whether the credential
status is checked or not. I've never understood the purpose of specifying what
checks the verifier should run. I expect that when I pass a credential, it
should check all the spec-dictated things (proof, expiration, etc.)

Markus: I agree, i think the options are not even defined properly but the
test suite does stuff the api spec does not describe....
... validation should be out off scope, we should leave comments on issues.
... regarding 62 "the check algorithm registry..."... seems like folks think
its harmful to allow ignoring checks.

... [issue ](https://github.com/w3c-ccg/vc-http-api/issues/58)

Dimitry: why do we have standalone verifiers in the first place? why not have
the app just verify things... some proof methods require resources that mobile
apps don't have... but that only applies to certain things... like proof....
the spec should only require checks that apply to "all proof types".

Markus: what check options do we need?

Dimitry: none.

Markus: Lets look at 59... need to define verify... what is in scope or out of
scope.... some we do already...
... is the presentation meeting some validation requirements (we think its out
of scope)... can we address this issue?
... we should look at all items that are verification, and only do those.

... any thoughts on this?

... one of the points in this list is checking if a presentation is expired....
... checking roots of trust, seems like validation

Markus: thats all for now.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/

Received on Sunday, 17 October 2021 20:55:50 UTC