W3C home > Mailing lists > Public > public-credentials@w3.org > January 2022

[MINUTES] VC API Work Item Telecon 2022-01-11

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 11 Jan 2022 20:38:13 -0500
To: W3C Credentials CG <public-credentials@w3.org>
Message-ID: <822e93f8-f52f-0d57-bb9d-e93b076b9645@digitalbazaar.com>
Thanks to Our Robot Overlords for scribing this week!

The transcript for the call is now available here:


Full text of the discussion follows for W3C archival purposes.
Audio of the meeting is available at the following location:


VC API Task Force Transcript for 2022-01-11

  1. Introductions and Reintroductions
  2. Relevant Community Updates
  3. Verifiable Credential Refresh 2021
  4. Issuer Automation Pull Request
  Manu Sporny, Orie Steele, Markus Sabadello, Mike Varley, Mahmoud Alkhraishi
  Our Robot Overlords
  Manu Sporny, Justin Richer, Mike Prorock, Markus Sabadello,
  Tobias Looker, Mahmoud Alkhraishi, Joe Andrieu, Rolson Quadras,
  Juan Caballero, TallTed // Ted Thibodeau (he/him)
  (OpenLinkSw.com), brentz, Eric Schuh, Phil L (P1), Adrian
  Gropper, Orie Steele, Kerri Lemoie, TallTed // Ted Thibodeau Jr
  (via iPhone), Dmitri Zagidulin, James Chartrand, Phil (T3), Brian

Our Robot Overlords are scribing.
Manu Sporny:  Alright welcome everyone to the VC API call this is
  January 11th 2022.
Manu Sporny:  We are trying auto-transcription today, we'll see
  how it does it typically does a terrible job -- but you know --
  let's just give it a shot.
Manu Sporny:  Our agenda for today was sent out last Sunday.
Manu Sporny:  On the agenda today we just have agenda review,
  which is this, some introductions for anyone that's needed to
  call any relevant Community updates.
Manu Sporny:  I'll do a quick overview of verifiable credential
  refresh 2021, new spec that uses VC API -- not meant to be a
  debate just kind of like a heads up kind of thing. We'll then
  talk about then some pull requests -- there's a workflow
  automation request that I put in that Orie has been heavily
  engaged in, and that Marcus has been heavily engaged in. Thanks
  for being here Marcus, I know it's late your time -- so we will
  talk about that and then do issue processing with any time that's
  left over.
Manu Sporny:  Any updates that folks would want to make to the
Manu Sporny:  Okay, then we'll go with that agenda.
Manu Sporny:  For those of you that might have missed it; Chrome
  97 was just released 7 days ago and it seems to be semi-busted
  with its audio. You may need to use Firefox or Safari or the
  Jitsi App or dial-in or chromium version before 97 -- all this
  should work, Chrome 97 is busted.
<tobias_looker> Thanks manu :) was scratching my head why audio
  wasn't working

Topic: Introductions and Reintroductions

Manu Sporny:  Let's do introductions and reintroductions, anyone
  new to call? Anyone that wants to provide a reintroduction or has
  anything changed with you?, or you just want to reintroduce
  yourself to the group.
Manu Sporny:  Alright if there's no one that wants to re-intro
  themselves, let's move on

Topic: Relevant Community Updates

Manu Sporny:  We will go on with the rest of the agenda. Next
  topic up is relevant Community updates.
<juan_caballero_(spruce)> 💪🌲
Manu Sporny:  The only Community update I have is that, I mean,
  it's no secret the DHS SVIP program is going to run a set of
  interoperability tests throughout this year. We expect that some
  of that work is going to happen in this group. This is an open
  invitation for anyone to participate -- we're really trying hard
  to do all that work out in the open, in public, and so the
  interop tests, which will be public, they'll be some of them
  maybe working elsewhere, but they're meant to be set up so anyone
  can participate. So you do not have to be in the DHS SVIP program
  to participate in the interop tests. Spruce is a great example of
  a company that was not an SVIP company that still went and
  demonstrated interop amongst a lot of the test suites.
Mike Prorock:  We will likely be running the supply chain and
  traceability side over in the trace work item, but you know,
  there's overlap with apis here.
Mike Prorock:  Would love to it if other vendors would like to
  pass those tests. Happy to help you get pointed in the right
  direction on that stuff.
Manu Sporny:  Awesome, great thanks Mike I do think it would be
  super interesting if companies that have nothing to do with
  traceability were put into that test to see how far you get.
Mike Prorock:  Fantastic, which is why I was bringing it up on
  this call.
Manu Sporny:  Okay, great, so I'm sure we'll see vendors
  volunteering to be subjected to things they've never seen before
  and seeing if they interop -- that's the best kind of interop.
Manu Sporny:  Any other relevant Community updates?
Manu Sporny:  Or wishes for this year?
<adrian_gropper> Don't ask me that :)
Manu Sporny:  Surely, you guys want something to happen this year
Mike Prorock: https://github.com/w3c-ccg/traceability-interop
<orie> I wish for the W3C to become a Legal Entity.
Manu Sporny:  Laughing at Adrian and Orie's comments.
Joe Andrieu:  My sincere wishes for the Jitsi audio to work.
Manu Sporny:  Your wish and mine, my friend.
<mprorock> ROFL @orie
Mike Prorock:  Joe, it worked!?
Joe Andrieu:  How did it work!?
Mike Prorock:  I heard your voice.
<kerri_lemoie> :P
Manu Sporny:  We're one-for-one so far this year on wishes
  granted for this year!
Manu Sporny:  Ok, the next up is Verifiable Credential Refresh.

Topic: Verifiable Credential Refresh 2021

Manu Sporny:  Here is a link to that spec.
Manu Sporny: https://digitalbazaar.github.io/vc-refresh-2021/
Manu Sporny:  Here's a spec for verifiable credential refresh
  that we sent out sent out last year. We're proposing soon as a
  CCG work item. We're saying we'd like it to become one we do need
  a co-sponsor on it, so if any of you are interested in being a
  co-sponsor of the work item, that would be greatly appreciated.
Manu Sporny:  The purpose of this spec is basically to refresh
  your VC when it's about to expire, with holder consent.
Manu Sporny:  The Assumption here is that you have holder, you
  have done some kind of holder interaction that's like do you want
  us to refresh this credential -- renew this credentialing, its
  expiring, and the person's clicks okay. They say "yeah I want
  that". This is being applied to the DHS SVIP Permanent Resident
  Card use case. That's a high level.
Orie Steele:  I've been following this work for sometime; I think
  it's really awesome work. I guess it's a trend that I'm noticing,
  as there's revocation lists, now credential refresh stuff,
  there's the VP request spec, and this call is the VC API. So, I
  guess my main question is what are their assets of the
  specification that are specific to the VC API, and if so why is
  the specification need to be in a separate place or another way
  of thinking about it might be like -- it is there is it supposed
  to be better handled in the VP request spec?
Orie Steele:  Different versions of this but I think folks
  attending this call, it becomes really hard to tell what this
  call is about when all of the work is split across so many
  different smaller specifications of the CCG. So, this seems like
  a risk to some degree if we continue to do that in the future. I
  think the work is very valuable regardless of where it happens,
  I'm just trying to get a sense as to what your thoughts are
  regarding the VC API call, which were on today, and its
  relationship to this work.
<mprorock> Follow on, honestly should we note on some of these
  things that they might be intended to merge into main VC  API
Manu Sporny:  Yeah excellent question. Let me go to the Q, I
  don't want to jump in front of folks. I will answer that when the
  queue gets to me.
Mike Prorock:  I have kind of a follow on note that was in the
Tobias Looker:  This appears to be a data model extension spec,
  and a protocol definition spec.
Tobias Looker:  What is the relationship, can we move some of
  this stuff into the main VC Data Model spec, how would that be
Tobias Looker:  Is this mean to function more as a registry for
  all the refresh specs?
Manu Sporny:  Also, excellent question, Tobias -- I promise I
  will answer all those things when it gets to my point in the
  queue. Joe, you're up next.
Joe Andrieu:  Yeah, I just want to share my my sense of this.
  From the beginning is at the VC API was about harmonizing
  different work different people are doing in different places.
  Some of which had already emerged as their own specs on their
  own, so I'm supportive of building something that's harmonizing
  rather than a single monolithic API that we have to fight over
  every little detail so.
<orie> Agree with you Joe.
Manu Sporny:  Great thanks Joe, that does go a bit to answering
  the questions asked so far.
Adrian Gropper:  Shouldn't we wait to do this work until after we
  do Authorization? Perhaps Justin can weigh in.
<mprorock> no.
Manu Sporny:  Alright thanks Adrian Justin do you want to respond
  to that.
Justin Richer:  Yeah, sure, I'll respond -- No.
Justin Richer:  GNAP is fundamentally about getting an artifact
  that gives you access to apis.
Justin Richer:  So, refreshing a credential could both be an API
  that is protected, but as the group decided months ago that is
  not something that this group wants to think about right now for
  reasons I disagree with, but have been discussed another major
  aspect is that this is the kind of thing that could provide input
  to a GNAP authorization server, what as it's making its
  authorization decision and that's where I see the real value of
  connecting these two types of protocols... but it's not really an
  overlap in that case either, so from what little I understand,
  this is about VC refresh, not authorization.
Justin Richer:  I don't believe that there is any type of
Justin Richer:  Unless I'm missing something.
Manu Sporny:  I don't think you're missing anything, Justin, my
  read is the same as yours. Let me try and quickly answer folks
  questions -- first, why a different spec the VC data model?
Manu Sporny:  Sorry did not have this link ready -- finding it --
  there it is: https://w3c.github.io/vc-data-model/#refreshing
Manu Sporny:  We contemplated something that goes in
  refreshService at like above... but we never defined what it was.
  There is a data model that goes along with it and almost
  certainly a protocol that goes along with it. So we always needed
  somewhere to define a data model and protocol for refresh. There
  will probably be other types of refresh services out there and
  they may be different specs. It's a bit too early to tell but
  having one like gigantic spec that handles all refresh across the
  entire VC ecosystem is that monolithic approach that Joe
  mentioned -- that might not be a good strategy, so we're trying
  to define at least a data model and then how the data model is
  going to use a protocol. So that's what this new spec does for
Manu Sporny:  This spec defines a data model, a way of doing
  manual refresh, and automatic refresh. The language is kinda
  wrong here... we want mediated and unmediated refresh, really.
  Automated refresh happens automatically, is completely
  machine-driven. Mediated expects a web browser to appear in the
  process where an individual human being participates.
Manu Sporny:  That can be done in a fully automated fashion
  presuming a that the holder has consented to doing that kind of
  thing. We've got data model -- that's one of the purposes of the
  specification, and then the other one is the defining a protocol,
  at what we've tried to do is reuse the VC API entirely. There's a
  different PR that we'll talk about later in the call that does
  that, but what we're trying to do here is to outline a protocol
  here that really just defers almost everything to the VC API.
  What we're saying is we would like the data model to express
  certain things that let you use the vanilla VC API to do all the
  refreshing, and we give an example of what that back-and-forth
  might look like here in the examples in a four step process with
Manu Sporny:   It's meant to map to the VC API directly.
Manu Sporny:   So, that's why its not separate specs. If we were
  to take this refresh data model and put it into the VC API spec,
  that might be a bit weird because the VC API isn't really about
  internal VC Data Model specifics.
Manu Sporny:  Some people might disagree, but it might be weird
  to put the refresh spec into the VC API because that presumes
  that we were solving solving refresh for everything and that's
  probably not the case.
Manu Sporny:  We allow for multiple data models and multiple
  protocols for refresh because some people might not use VC API to
  do refresh in the future. Perhaps some sort of bluetooth refresh
  mechanism will come out, and that's definitely not going to use
  VC API over HTTP.
Manu Sporny:  I hope that answered everyone's questions, let me
  know if I missed something.
Markus Sabadello:  This makes a lot of sense to me, the way it is
  modular, it's basically the same pattern as the Data Integrity
  work, proofs, and other parts of the VC Data Model. VC Data Model
  provides the central extension points, and extensions are in
  other specifications.
<orie> exactly markus... but this is the first that I am aware
  that depends on VC API?
Mike Prorock:  That's similar to what Markus was saying, I mean
  this makes total sense, I guess my question is more around the
  long-term path for this. It's more about the land between the
  data model extensions and protocol... whats the outbound path
<orie> StatusList depends of VC Data Model, this appears to
  depend on VC Data Model and VC API Draft?
Mike Prorock:  How does this go into the VC working group? It
  feels like the data model stuff should almost move over to the
  data model proper right from the start, and then the protocol
  might be better incubated here and then standardized elsewhere.
Mike Prorock:  What are you thinking there from a standardization
  path standpoint?
Orie Steele:  So I just wanted to be clear, my understanding of
  the the refresh is that it takes a concrete dependency on the VC
  data model which is similar to the status list spec. But this is
  the first one that depends on VC Data Model and VC API, right?
<mprorock> Traceability work does the same thing.
Manu Sporny:  Yeah, aside from Traceability, I don't know of
  any... but that was deliberate... we need to start standardizing
  these protocols.
<orie> There were objections when we did this, with
  Traceability... I guess the door is open now?
Manu Sporny:  We are starting to signal pretty strongly to W3C
  that we have done data model, we're doing data integrity, and now
  we have to do protocol. So, it's to apply a kind of
  standardization pressure on W3C proper... these things are coming
  down the pipeline. We were forced to only do data model at W3C in
  the beginning, but we've established work at W3C now... we're
  going to do protocol next, the company objecting to that work has
  now joined us, so it might be easier.
Manu Sporny:  Status list spec is interesting, we have a
  normative dependency on VC Data Model, but we did normatively
  depend on a protocol spec -- HTTP, it just so happened that that
  was done and we could just use it.
<orie> I was limiting my criticism to drafts that depend on
  drafts... HTTP and W3C VC Data Model are standards... but yes,
Manu Sporny:  Again, I'm just proposing a possible path forward.
  We have a VC Data Model standard, we have a VCWG, we are doing
  Data Integrity next, once that's done, it's protocol... There is
  a pipeline here and we're just filling the pipeline.
Manu Sporny:  In the next rechartering as a non-normative work
  item and then when we recharter again which we can do within a
  year right I mean we can change your mind if things go quickly
  with the data Integrity stuff we can recharter and then take on
  the VC API work, and possibly things that depend on it (like
  status list, refresh, etc.).
Mike Prorock:  Yeah.
Mike Prorock:  Make total sense. We know that protocol caused
  consternation in the past at W3C, so cautious for that reason.
Manu Sporny:  We've won at least one of the formal objectors over
  since that point in time.
Mike Prorock: +1
<orie> I would never assume someone won't formally object.
<orie> ever.
<orie> in fact, start assuming they will.
Manu Sporny:  Yeah, agree, people are still going to formally
  object over something.
Manu Sporny:  Any other questions on that before we move on?

Topic: Issuer Automation Pull Request

Manu Sporny:  This PR was raised as a non-normative basis for the
  credential refresh spec.
Manu Sporny:  Basically, this PR is about issuing through
  automation workflows... it says it's highly experimental, just a
  simple four-step back and forth protocol, gives examples w/o
  adding normative text.
Manu Sporny:  Orie, you've provided a bunch of good
  input/feedback, so thanks a ton for that. Could you please take
  us through your feedback?
Orie Steele:  Basically the original objection was that the PR
  was referring to an "interact" primitive, which was assumed to be
  part of the VP request spec, which is a assumed (I think)
  dependency of the VC API as it stands today, so let me share that
Orie Steele: https://github.com/w3c-ccg/vp-request-spec/pull/13
Orie Steele:  This is the change request I asked for -- define
  "interact" in VPR spec... and you did that in this PR.
Orie Steele:  This is where it belongs and now you're now
  providing an example in the VC API spec on how to use this
Orie Steele:  So we're now doing a second version of that, and if
  you're clever with using it, you can use it to present
  credentials from a holder to a verifier. Now this new pull
  request on the VC API is doing the same thing, except that
  there's this extra interact feature, which you can use and if you
  want to learn more about it you can go read the VP request spec.
Orie Steele:  We had no definition, and now we're adding a thing
  that has a definition, and it doesn't preclude the existing flows
  that we have. I do think it fails to understand why there's
  existing flows were requested in first place, but that's not a
  reason to hold off the pull request. We can continue to work on
Orie Steele:  So I just I'm trying to connect all the dots for
  folks, to understand everything you have to go read a couple
  other pull request to get the background information.
<orie> Is it compatible with GNAP?
<orie> can you use GNAP with "interact"?
<orie> these are good questions.
Manu Sporny:  Justin, I'm interested in your thoughts on
  interact, because it was inspired by GNAP. Do you have any
  high-level thoughts to start, or do you want some more time to
  think about it since we just dumped this question on you.
Justin Richer:  I have not had a chance to read this in any depth
  whatsoever, but I can say that this kind of pattern is exactly
  the type of connection point we were talking about in the GNAP
  process. The authorization server is allowed to say: "ere's how I
  can do the authorization in the client to negotiate ways to
  interact with the end-user", and that's what the interact block
  is all about so when the client shows up and it says that I want
  to talk to the AS -- these are the ways that I can interact with.
Justin Richer:  With the end-user if you need to, the AS can come
  back and say: "Yes, this is how I will support that interaction
  because I need to get in touch with the user somehow now". I'm
  not convinced from just reading what's on the screen here that
  this is actually doing the same thing, so I don't know if it's
  the right application of that.
Justin Richer:  We're not doing the same kind of negotiation, I
  believe, here.
Justin Richer:  We're not doing the same kind of delegation.
Justin Richer:  This is just kind of access.
Justin Richer:  So, I don't think it's quite the same thing but
  again I have not had a chance to read through this in any depth,
  so I'm not really qualified to speak on what was meant here.
Justin Richer:  Maybe Dimitri can fill that in, though?
Justin Richer:  I think he understands both sides a little bit
Manu Sporny:  Go ahead Dimitri.
Dmitri Zagidulin:  So yeah, the interactive section was
  definitely inspired by GNAP.
Dmitri Zagidulin:  It's both true that this is not trying to
  replace GNAP.
Dmitri Zagidulin:  This is more this whole mediated and
  unmediated flows is trying to model.
Dmitri Zagidulin:  Iterative, between client server that has to
  do with prerequisites on the server side.
Dmitri Zagidulin:  So client asking: "Please issue me this
  credential or please renew this credential", and the server
  saying: "In order to do that, I need the following things and
  here's where you can submit them."
Dmitri Zagidulin:  That's what the "interact" block is doing.
Dmitri Zagidulin:  So, it's inspired by GNAP, not trying to
  compete with it.
Justin Richer:  Can I respond to that?
Manu Sporny:  Please.
Justin Richer:  Thank you, I realize I'm jumping the queue my
Justin Richer:  Okay, so that does make more sense now.
Justin Richer:  As is usually the case, in systems design when
  you see things that are in inspired and similar, it does start to
  beg the question: "Is there a common abstraction or,
  cross-reference, that could even be used here?"
Justin Richer:  So, Dimitri, I'm actually going to request invite
  you to present at the GNAP interim meeting next week, if you're
  at all available? I can give you 20 minutes or so to very roughly
  present this idea to the GNAP working group and cuz I think it's
Justin Richer:  I do think this pattern is interesting, and I
  think that might be something that the networking group would
  like to take a look at if you're available.
Dmitri Zagidulin:  I would love to, yeah, let's connect and cross
  pollinate the idea.
Manu Sporny:  Awesome, this is exactly it is exactly the type of
  feedback and conversation I was hoping would happen. Justin, we
  just want to make sure that if we're using "interact" here, it
  doesn't screw things up with GNAP. If it's going to send people
  down the wrong path, or a misunderstanding, we will rename it if
  it turns out this is a bad idea. We're trying it out because we
  think there's probably some kind of generic pattern here that's
Justin Richer:  Yeah and I really do believe in the power of this
  pattern, otherwise we wouldn't be building GNAP off of this. For
  those unfamiliar with how works, this whole interaction section
  is one of the key protocol differentiators (for GNAP).
Justin Richer:  Today, you have to sort of decide ahead of time
  what your Grant type is and then you're kind of stuck with in
  that process. In GNAP, this interact section that allows this
  decision to be made at runtime where you don't have to know
  everything ahead of time. I'm very much a fan of this pattern and
  I would like these two groups actually try to figure out if there
  is either commonality or as Manu said, we do need to be carefully
  distinct from each other because if they're similar patterns.
Justin Richer:  We don't want people assuming that n extension
  that gets written for VC API can just be dropped into a GNAP
<orie> See also
<mprorock> you can downgrade tokens in oauth
<justin_richer> yes you can downscope in Oauth, I wrote that
  section in the spec :)
Adrian Gropper:  Yes, so apologies for my inability to understand
  the protocol work. I think I can help by basically saying what my
  perspective is on this conversation. I'm interested from a
  privacy perspective that every request falls to the authorization
  server regardless of what authorization server is associated with
  what domain whether it's the issuer  or the holder or something
Adrian Gropper:  It sounds to me like we're planning to send
  requests and this case refresh requests to the resource server,
  the issuer as a resource server. It raises all sorts of issues in
  my mind, I apologize if I'm getting it wrong cuz I'm too high
  level for the discussion at hand, but that's what I'm trying to
  get to.
<justin_richer> Details for the interim meeting next week:
<mprorock> so you want a central point of failure and control?
<orie> Room_641A
Manu Sporny:  We'll have time to talk about this -- this is all
  new stuff, so I think everyone's going to have to get their mind
  wrapped around it before we can have a productive discussion in
  the group. This is just a heads up that this stuff is out there
  and there is a PR.
Manu Sporny:  I heard Orie say that he's okay with the PR so far.
  It would be good for other people to take a look at the multiple
  PR's and see what they think about them. Remember this is all
  experimental stuff so we're trying to be a bit faster about
  moving these things in, but it would be good to get a couple more
  reviews in before we pull it in. There were a few open questions
  that Orie and Markus raised in the PR that might be good to put
  out to the group.
Mike Prorock:  From a nerd perspective, I hate to say this, but I
  kind of want to see a diagram and some plain English.
<orie> Lets volunteer Joe : )
<orie> he makes diagrams!
Manu Sporny: :Laughs: Joe's good work reduced to "He makes
Mike Prorock:  It's just a feeling a little bit in nebulous, and
  a feeling a little bit like some of the language is just so in
  the weeds.
Dmitri Zagidulin: @Mprorock: could I interest you in
  https://github.com/w3c-ccg/vc-api/issues/245 ?
Mike Prorock:  And I kind of want it in there now, but it might
  just be a room for improvement thing.
<dmitriz> it doesn't have diagram, but has step by step examples
Manu Sporny:  Yes, I can do a diagram, no problem, swim lanes,
  got it.
Mike Prorock:  Yeah, that would be awesome.
Mike Prorock:  First glance I can't be the only programmer that's
  been working on that work stuff for 20-plus years that's going to
  look at this go: "Oh yeah, it might be useful for something
Manu Sporny:  Agreed, it did cross my mind when I was writing the
  PR and then I just sort of ran out of time. I can put a swimlane
  diagram in the PR.
Mike Prorock: +1
Dmitri Zagidulin:  I just wanted to respond to Mike, could I
  interest you in the write-up and VC API issue 245 -- no diagrams,
  but it does have step-by-step JSON examples.
Dmitri Zagidulin:  It differs from Manu's Proposal in like one
  API endpoint, but same for the rest.
Orie Steele:  You can do whatever you want in the refresh spec
  because it's not a CCG work item, it's under Digital Bazaar right
  now, so you don't need any permission to update that document.
Manu Sporny:  That's true, thanks for the reminder, I had totally
  forgotten about that.
Adrian Gropper:  A quick question, I saw a comment in the chat
  about a single point of failure. I think it was a reference to
  something I might have said and I'm curious what triggered that?
Mike Prorock:  Yeah, I did and I think Orie dropped one of the
  many things I was thinking, which is a certain room in a building
  that you could probably Wikipedia if you care to (central routing
  point for all communication)... I always get very concerned when
  I hear things like: "Oh, all of this stuff needs to route through
  the authorization service."
Mike Prorock:  Snooping attack vector.
<orie> I get concerned anytime i hear choke point... some guys
  like squeezing choke points.
Mike Prorock: +1 Orie
Adrian Gropper:  Well to the extent that we're concerned to align
  with a zero trust architecture mandates, so you know when the
  federal procurement. In general, I think it's very much worth
  discussing the point that Mike brought up because in my opinion
  one could look at your  architecture and say the problem is Zero
  Trust Architecture. I'll just leave it at that, thank you.
<mprorock> off topic, but yes important
Manu Sporny:  I wanted to point out a couple of things, food for
  thought, and then kickoff a discussion on any of them.
Manu Sporny:  I wanted to point out here what's being proposed in
  the auto-refresh spec is that each workflow is kicked off by
  hitting a URL, I think with that we can be aligned with what the
  traceability folks are doing in step 1. Step 2 so the first one
  is I want to present something to you or I want to engage in a
  flow with you in a workflow with you that's the first client to
  server message the server response back with okay if you want to
  do that here the things I need from you.
Manu Sporny:  So, lots of alignment on step 2 and 3.
Manu Sporny:  Step 4, we don't want this to be tied to verifiable
  presentation request in fact we want to allow for extensions
  around for alternative verifiable for presentation exchange
  languages different ones here, like WACI/PeX.
Manu Sporny:  Partly, because you know, maybe VPR is the wrong
  thing to do.
<orie> WACI/PeX isn't a work item, I don't want to comment on it.
Manu Sporny:  And we might want VPR out when we find out that it
  was a terrible choice.
<orie> but I don't think thats a good strategy.
Manu Sporny:  So we could potentially do different presentation
  protocols like WACI/PeX or DIDComm-based thing or some binary
  Bluetooth whatchamajigger. The key here is that we want to be
  able to have some agility/extensibility here... but we will focus
  on VPR first. I just wanted to highlight that we may want to
  enable other protocols and presentation request mechanisms.
Orie Steele: +1 To starting with 1 thing, and not precluding
<mprorock> can we bring this in as a work item to CCG?
Manu Sporny:  Or he saying he doesn't like to this is Reggie
  that's totally fine just putting it out there for people to to
  think about yes agreed Glory let's start with one thing and we
  remodeling it you know VPR.
<mprorock> i would feel better on call time and contributing if
  it were and covered by full IPR
Manu Sporny:  Yes, we can do that, Mike... just need a
<juan_caballero_(spruce)> (to the previous point about /available
  endpoint initiation)
Manu Sporny:  Markus also raised a really good point -- don't we
  want to use other authz/authn strategies -- yes, we do, but we
  don't want to pick one. We might be able to say it's open ended,
  use what's important to you.
Manu Sporny:  Step 4 also disagrees between workflows and
  traceability. Autorefresh gives you back a VP at the end...
  Traceability tells you if the VP succeeded or failed. So,
  alignment needs to happen there.
Manu Sporny:  For the traceability stuff is kind of yeah we got
  your presentation everything validated. What we're proposing with
  auto-refresh that we want to be able to do a continuation into
  another process, now that you've passed this process, so we
  should probably discuss in a future call and have a discussion
  around how do we reconcile those two kind of things.
Mike Prorock:  Yeah it just made a comment in the chat, and I
  didn't want it to get lost. I would feel better, like with this
  item, and I think the request back are both like Digital Bazaar
  items, I feel a lot better if we're dedicating call time to CCG
  work items.
Mike Prorock:  Just as we're starting to get more eyes in and
  stuff like that.
Orie Steele: https://w3c-ccg.github.io/vp-request-spec/ is
  contributed to by Secure Key... supposedly.
Manu Sporny:  Agreed, VPR is already a CCG work item.
Manu Sporny:  So everyone has seen what we're proposing to do, do
  we have anyone that wants to be a co-sponsor on the on the spec?
<orie> You might try the regular call time and mailing list
Manu Sporny:  I'll send something out to the mailing list, I was
  just seeing if we can pick one up here, then we're done. If not,
  we'll take it to the mailing list, so that's what we're waiting
  on, Mike... we definitely want this in the CCG as soon as
  possible, but we need a co-sponsor.
<mprorock> if we can get this aligned better with trace, I would
  happily co-sponsor.
Manu Sporny:  Alright I'll send it out to the the mailing list
  with the request.
Manu Sporny:  All right, and that's a call thanks everyone for
  the call day.
<orie> Great work on this.
Manu Sporny:  Thank you to our Robot Overlords for scribing.
Manu Sporny:  Chat with everyone next week. Thanks all, bye.

Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
Received on Wednesday, 12 January 2022 01:38:40 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:28 UTC