<manu> scribe: dlongley
burn: Any requests for changes to the agenda?
manu: I think I heard you say PR review but I'm not positive.
burn: I did.
manu: Just have a couple of inputs on the PRs.
burn: PR review/readiness of the data model spec for external review.
manu: Great, thanks.
burn: We have some people visiting for the first time today, Alex?
Alex: Alex Ortiz, very excited to be here. Zeno Labs, Building out Life ID, first WG we've joined, hoping to create a better world through this technology.
Rudy: Rudy Maxwell with Zeno Labs, work closely with Alex, I'm the CTO where we're building a decentralized identity solution on the blockchain.
burn: Welcome everyone, happy to
have you here.
... No outstanding action items.
<burn> https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+no%3Aassignee
<Zakim> manu, you wanted to note they're not on IRC...
burn: Manu update?
manu: A couple of requests last
week to add every open issue that we have ... I think I got all
of them except for maybe Clare's. It was added after I did the
review. The spec has a reference for every issue but Clare's
now.
... Spec is ready for external review, the other PR won't make
it this week. We are as ready as we can be for early review.
That's where we are. I guess the next question, to the chairs,
is there anything I can do before like a timestamped version or
anything else to be cleaned up in the spec before sending it
out.
burn: A timestamped version would help, we want to be able to send both links, current and timestamped so it isn't changing under the reviewers.
manu: Want me to prep that?
burn: Yes, please.
manu: Ok, I'll do it.
<manu> ACTION: Manu to create time-stamped version of VC Data Model spec for external review.
burn: Thanks, Manu.
... I think we're good, we already discussed last week who it's
going to. I'll email directly if we have any other requests. I
will try to get that out in the next day or two. Anything else
on that topic?
<burn> https://github.com/w3c/vc-data-model/pulls
<burn> PR `99
<burn> PR 199
https://github.com/w3c/vc-data-model/pull/199
manu: There are at least two
issues that are raised. Letting verifiers know how long to
cache before having to check it again.
... There's a PR with a DSL to achieve the result, as features
rolled in we've seen things get complex.
... Dave Longley has some thoughts, I'll stop there.
<manu> dlongley: I've put my thoughts into the PR... saw this coming across and I'm worried that we're getting too far ahead of this problem. I understand that people wanted caching, let's reuse technology to piggy back off of existing technology... that will create conflicts/complexities by doing that.
<manu> dlongley: The problem space may not be the same there, there is potentially wider scope that the language is designed to solve... lots of potential issues. We're getting ahead of ourselves... we haven't contacted the problem enough... we need to clearly dilineate use cases and requirements.
<manu> dlongley: We could spend a lot of time working on this, spending time on something we don't need to work on.
<manu> dlongley: let's see if we can solve this in a minimal way.
burn: I will echo what you said.
Caching is not this group's expertise. Lots of people have
spent a lot of time thinking about how caching should work. It
would be nice to not have to treat it as a new problem.
... Manu, I know you were hoping to get comments from others
and the two others that would be most likely to comment aren't
here today.
manu: I have little faith that
this PR will make it, the only thing that might make it is the
refresh service. Just thinking about the implementation burden
-- we're talking about a state machine for caching and it's
crazy complicated.
... The issue that Matt Stone raised presumed the feature. We
have other things that give you that capability, like
expirationDate and revocation lists and status fields. The
rules today are really simple -- you can cache the credential
until it expires and you must check the status field. You must
check it dependent on your business process.
... That addresses the driver's license use case that Matt put
forward. My suggestion is to close the PR and create a new one
for refresh service URL and say we aren't going to support TTL
until there are more use cases and we can demonstrate that
expirationDate and status field aren't adequate for the use
cases.
burn: I think what you just said was clearer in terms of a recommendation for a path forward than what's in the PR -- could you add that to the PR as a suggestion?
manu: Sure.
burn: I believe we are still
waiting on the other two PRs -- Terms Of Use and Subject !=
Holder. I'd ask David Chadwick for status but he's not here
today.
... Any thoughts on those?
<Zakim> manu, you wanted to provide some thoughts.
manu: There's this concept of
delegation that keeps coming up relentlessly. Should a VC be
used to delegate or should OCAPs be used to delegate?
... We need Chris Webber to weigh in on the issue. We need
other people in the group to weigh in because it's a
fundamental design issue. What's holding things up is the
concept of delegation and having one's credential to someone
else.
cwebber2: I can review it today. I will comment on it.
https://github.com/w3c/vc-data-model/pull/198
manu: Specifically the delegation
aspect.
... We might want to pull that into the group and have a time
boxed discussion on it.
burn: I actually think that's a good idea because it's come up a variety of times.
<scribe> ACTION: Chairs to schedule a time to specifically discuss whether VCs will do delegation.
burn: Anything else?
<burn> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
burn: For those just joining today it's pretty rare that we'll get to the last item on the agenda, usually a stretch item... but we made it today.
https://github.com/w3c/vc-data-model/issues/139
manu: So the refresh service will address this. So this is being actively addressed.
burn: I'll mark this one to say a PR exists.
https://github.com/w3c/vc-data-model/issues/76
<Zakim> manu, you wanted to note that if gkellogg doesn't work on it, it's unlikely to get done.
manu: If Gregg doesn't work on
this one, I doubt anyone else in the group is going to -- I
don't know of any production systems using SHACL as the
constraint language, I do know that json-schema is being
used.
... The CCG is doing their Bitcoin Hackathon for VCs and DIDs
this week. The context was out of date and I updated the
context by hand over the weekend. We don't have an open issue
for aligning the context with the spec -- we should open an
issue for that.
... And potentially publish it -- we didn't do that previously
because there were things in production that we didn't want to
mess with.
burn: This is one of those where
we need someone to take it on or it won't happen.
... I'm going to do a mention to Reto as well to see if he has
any suggestions -- if he's willing to take on trying to make
progress here.
tzviya: Benjamin Young is on vacation now but we've done work with SHACL -- I can't volunteer his time and he can't do it himself but I suspect he'd be able to help out.
burn: I will mark this one as deferred until we hear otherwise.
https://github.com/w3c/vc-data-model/issues/72
burn: PR 72 is just waiting on this discussion.
https://github.com/w3c/vc-data-model/issues/129
<Zakim> manu, you wanted to suggest we do not support this in this version?
manu: I think we're hitting that
time in the WG where we're just going to start dropping
features very aggressively whether we think it's a good idea
long term or not.
... I suggest we drop this one.
... It would be nice to have it there, JSON-LD 1.1 is currently
happening, we have this new forced layout mechanism, developers
will do this anyway -- they will have json-schema that
validates input if they do validation at all, we don't have to
modify the spec in any way to support that.
... I say we push that off to version 2 if we do it at all.
burn: I tend to agree and it
would be good if you put those comments into the issue.
... I'd prefer you do a suggestion to defer.
... There was agreement from David that this should happen and
then it went silent.
... It will probably effectively get deferred within a few
weeks.
https://github.com/w3c/vc-data-model/issues/128
manu: It feels like the same issue.
burn: If you could put a reference to your comments in 129 in 128 that would be good.
manu: Ok.
https://github.com/w3c/vc-data-model/issues/162
<manu> dlongley: This is sort of a work in progress, I don't think we should have an issue... we're working on this problem right now, getting WebAuthn to work with Verifiable Presentations. We may put something in the spec, but may not put it in the spec. Nothing to say yet, it's being explored with implementations.
<manu> burn: Could we get ding'ed by another group when reviewing for this?
<manu> dlongley: Well, we have an issue marker in the spec... that should prevent that sort of behavior.
<manu> burn: My concern was not saying anything about it in the end.
<manu> dlongley: Let's mark it as an issue in the spec, see where we end up.
<manu> burn: Can you put the current plan regarding figuring this out, that would be good.
https://github.com/w3c/vc-data-model/issues/105
burn: We've had a lot of changes in the text in the spec and I think David needs to review this one again.
https://github.com/w3c/vc-data-model/issues/157
<manu> dlongley: If I remember correctly, David said that verifiers need to throw an error when they don't understand certain properties. I think we can close this issue.
https://github.com/w3c/vc-data-model/issues/93
burn: I'm going to ask Kim to take a look.
<Zakim> manu, you wanted to provide input on JOSE/JWT...
manu: I've got more information
on this item. It will unfortunately complicate
everything.
... We've been looking into WebAuthn -- and it has completely
bypassed the JOSE stack and is using COSE/CBOR stuff. We have a
spec coming out of W3C that has settled on CBOR for the
low-level implementation, the data syntax and COSE, which is
basically digital signatures on top of CBOR.
... This is a newer set of specifications than the JOSE stack.
We're trying to integrate the WebAuthn stuff with the VC stuff
and if they are fully built on top of COSE that raises a
question as to whether or not the proof mechanisms should be as
well.
... That adds another path forward, but it's pretty clear what
the next gen specs are picking and it's COSE instead of
JOSE.
... There has been a discussion on "why aren't we using
JWS/JWT" that kind of stuff -- we have switched our
implementations to use JWS and now the world may be moving on
to COSE based signatures.
burn: That's a good update.
... In terms of closing issues, because that's what I like ...
I think it might be good to put some of that commentary in the
issue and flag Kim on this. I don't know, what do you think? Do
we just need to wipe this and put in a new issue at this
point?
manu: All this stuff is driven by
implementors, it feels like the uPort folks are supporting JOSE
but during the last call they were saying they were fine with
whatever ... here's the issue, it will make the implementations
more and more complex the more switches we do. We have an
opportunity to leapfrog the old stuff and go to the new
stuff.
... If the new stuff is COSE then we can completely skip JOSE
and we don't have to pull that entire stack of libraries, which
are non-trivial in their implementation burden, into our
implementation.
... I would prefer that we skip it and just use COSE. We need
to figure out how other people that do want to use JOSE and JWT
feel about that.
burn: Thank you for reminding me
of something -- which is something I haven't officially
announced to the group yet. I forgot to mention that I am now
representing Consensys in this working group.
... I can't believe I hadn't mentioned that yet in this group.
The uPort folks probably have an opinion on that and I have to
get up to speed to do that.
... I do want to make sure the group is aware that I have
obligations to Consensys.
... Ok, I'm not sure where to go -- we really do need to get
proper input on this. It may be that the world is going in one
particular direction and everyone perhaps needs to get ready to
go that way, I don't know yet.
manu: This isn't critical path other than if the uPort folks want to express VCs as JWTs. The last time Pelle was talking to the group it seemed like the direction they wanted to go -- Nathan, I think you're on the call today, I don't know if the Sovrin/Evernym implementations are interested in using JWTs for this. We've mentioned multiple times some big downsides to doing that. This adds concerns.
<Zakim> nage, you wanted to comment on JWE
nage: My understanding is that there has been some talk of doing some JWE for agent to agent/identity to identity messaging. That's more in the scope of what the CCG has been working on. I can't say anything has been settled. Lots of controversy around that -- do we even need one standard as long as it's pluggable. Discussion should continue there, also discussion in DIF. I'll reach out to Kyle Hartog and if we can find out where uPort is we can be in a
good spot.
<manu> q_
agropper: I think our project on
the Self-Sovereign tech stack has a horse in this race, but
since I'm not doing the coding I'm not sure what to say about
it. The issue -- it's come up for a year now -- in the SST
stack we allow both DID and VC as well as OpenIDConnect as the
authentication and credential bearing mechanism into the UMA
server.
... We enable the individual to whitelist an ID provider or to
set policies relative to the VCs being presented. For a year
and a half now at every IIW I try to get these two communities
together OpenIDConnect, JOSE folks, and W3C. It sounds to me
like this issue belongs squarely in that discussion which I'd
like to have more broadly.
... This is an obvious use case to deal with as implementors
and what we do here.
manu: I agree with Adrian -- I think the problem here is that the conversation is not happening. We're not getting engagement from the people that want to use JWTs. The WG will end and it won't be done. Fundamentally someone has to step up that wants to do JWTs. The door is closing. Digital Bazaar is not interested in using JWTs as a mechanisms for VCs -- if you do want to use a JWT you can shove a VC into a JWT as is. We don't see this as an issue. If
you know someone who really wants to use JWTs (not just encapsulating it) but throwing out the encoding we have in the VC spec today and using something else -- please let them know they are running out of time.
<Zakim> burn, you wanted to suggest we schedule a call specifically for this and invite many participants
manu: To write that spec and do the implementation and get it into the group.
<nage> Link to JW* efforts https://github.com/sovrin-foundation/ssi-protocol/pull/2
manu: So, Dan, you may need to let uPort know that.
burn: I recommend we schedule a
call for this and send invitations. I hear you -- we're quite a
ways down the road here as well. We don't need things blowing
up. We do have to make one more attempt to let a variety of
groups know that they need to put up or shut up at this
point.
... And uPort is one of those groups but it sounds like they
aren't the only group.
... I don't want to touch issue #93 right now.
agropper: I will reach out to the folks w/UMA and OpenIdConnect if we do that call.
burn: Thank you. Whether or not they can come on that date is not the critical issue -- letting them know that this is their last chance to suggest a major direction change in the spec.
agropper: Can we decide today if we want to invite them? Someone can write a paragraph that I will send to them -- I'm not technical enough to write that paragraph. I'll work with somebody on the call today that can do that and forward it.
burn: I'll include you on the discuss on this in terms of scheduling.
agropper: Thank you.
burn: We're out of time --
anything else for today?
... Thanks to those that are visiting and to everyone who sat
through listening to review of old issues, talk to you next
week!
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/late, dialing in, sorry// Succeeded: s/manu/burn/ Present: Adrian_Gropper Allen_Brown Bob_Burke Chris_Webber Clare_Nelson Dan_Burnett Dave_Longley Ganesh_Annan Joe_Andrieu Manu_Sporny Nathan_George Rudy_Maxwell Ted_Thibodeau Tim_Tibbals Tzviya_Siegman Yancy_Ribbens dezell Regrets: Liam_Quin David_Chadwick Benjamin_Young Matt_Stone Found Scribe: dlongley Inferring ScribeNick: dlongley Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Jul/0006.html WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: chairs manu WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]