W3C home > Mailing lists > Public > public-credentials@w3.org > June 2016

Re: Verifiable Claims WG Proposal (presentation)

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 19 Jun 2016 20:37:15 -0400
To: public-credentials@w3.org
Message-ID: <57673ABB.6070101@digitalbazaar.com>
On 06/18/2016 09:06 PM, Timothy Holborn wrote:
> Firstly i want to note that what is likely to be progressed here is 
> 'verifiable claims' not identity from a baseline ID/AUTH
> perspective.

Correct. Verifiable Claims are tightly scoped (which is what W3C members
look for). Identity is anything but tightly scoped... or well defined...
and as a result, it tends to breed controversy.

> Let me know if i'm wrong with that assumption?

Your assumption is correct.

> I didn't see anything about HTTP-SIGNATURES nor Linked-Data, etc.
> Not sure if that should be highlighted somewhere.

HTTP Signatures are IETF territory.

https://tools.ietf.org/html/draft-cavage-http-signatures-05

Linked Data is poison to many charters. People have a visceral
(negative) reaction to it. That said, most everyone here is going to use
the version of Verifiable Claims that uses Linked Data. It's optional,
but we're seeing very strong support for it (and honestly, nothing else
is going to scale as well as it does for this particular problem -
extending the core data model w/o conflicting as the usage of the system
scales).

> As also noted; I really, really think your work on Web-DHT is kinda 
> awesome and i also think it has great potential scope for use beyond
> the scope (and in relation to it) of the Verifiable Claims
> Task-Force work-output.

Thank you, and it does.

> Yet, i do not think that work is effectively encapsulated in the
> work-output we want to progress with Web-Payments IG; nor do i think
> it's ready.

Correct.

> FWIW - i really dislike the idea of a block-chain managing ID/AUTH.

Agreed, for certain aspects of some definition of "blockchain". There
are uses of "blockchain" that make sense, there are others that are
completely out of place.

> Re: slides - Here's some notes.
> 
> Slide 5 says problem and mission goals which appears to relate to
> slide 4.
> 
> Perhaps if you could break slide 4 into 2 slides, both with
> dot-points, so you've got one slide with the problem. the other with
> the mission.
> 
> this suggestion is in-turn aimed at scoping what people agree on
> about the problem and the mission.  ie: give the claim some scope.

I was trying to condense the slides, we have very little time to make
our case at the face-to-face. That said, you're right, it doesn't feel
right and I'll make another pass on the slide deck taking what you said
into account (as well as the input of others).

> slide 8 - i was thinking their are two counterparts to this.  The
> first is the top 3 boxes which is the principle of what we're focused
> on.  The identity registry is still kinda alpha in its description -
> yes - it is drawn well, but the scoping for that 'identity registry'
> i think it's needed - but we're not sure how to do it yet? (not sure
> if that's an accurate characterisation...?)

Yes, that's accurate. We're trying to convey that there is a vision
beyond the initial WG and just put that vision out there. The message
we're trying to send is "the VCWG is the first step in a journey", so
that folks aren't surprised when we come back and start talking about
the Identity Registry.

Or, we may not - Verifiable Claims specifically allows for URIs for
subject identifiers. If some global, decentralized identity mechanism
that fits our requirements takes off (like Bitcoin or Linux did... and
becomes more or less ubiquitous), we wouldn't need to standardize
anything - de jure vs. de facto.

> 10 - title seems more defensive than is necessary.  Title could be 
> 'timeline' or something that denotes you've / we've been working on
> it for a while.

This was a direct question asked by W3C member companies.

> Initial documentation was all about 'identity' whereas the scope ATM
> is accurately described as 'verifiable claims' which is an element of
> identity but not 'identity' as may be debated.

The scope was always verifiable claims... which we called credentials at
first (a credential being a collection of verifiable claims). That's why
the Community Group is called the "Credentials Community Group" and not
the "Identity Community Group". We were very careful, from the
beginning, to not touch the electrified "identity" third rail.

Since that point, we have been distancing ourselves from identity even
more. Seeing a show we have 20 minutes to make the pitch, do you think
this detail is important enough to go into during the presentation? The
reason I haven't this time around is because it has derailed the
conversation when we dived into it before. This time around, if someone
says "so, you're trying to address identity, huh?" the response will be
"absolutely not, and I'm happy to explain why after we get through the
actual proposal, which is for verifiable claims".

> slide 11: Again - i think this can be put in a more positive light. 
> Some areas need continued incubation on the foundation of what it is
> we agree is ready to be moved forward.

Again, and unfortunately, a direct question asked by W3C Management.
We're attempting to respond to the direct questions w/ direct answers
rather than try to spin them in a more positive light. I'm concerned
that if we do too much "on the brighter side" presentation language,
which we've tried before, that people will think we haven't done our due
diligence, which is what happened before.

> I think what this slide communicates to me (having been around for a 
> while) is what whilst 'some' of the application of these works have 
> obtained traction - other elements of the work still need further R&D
> / incubation with a means in which to evaluate the elements that
> require further architectural consideration in-association to the
> elements we're all comfortable with and that now need to move forward
> on a basis of broad agreement (re: slide 5).

Agreed.

> another slide could be produced to highlight some of the areas in
> which this work has highlighted problems that we are actively working
> on as a group.

I'm concerned that doing that may derail the conversation and add more
stuff that isn't directly appropriate to the proposal that folks will
have to keep in their head.

> To describe the concept differently;  HTML has undergone various 
> implementations and 'standards releases' i'm sure throughout that
> sphere of works, some concepts were not yet ready for prime-time and
> so delayed, yet others were ready. in-turn relating to release cycles
> that aid with decision making for what they're agreeing to today; and
> what we're looking at for later releases (if that makes sense).  I
> also think it's probably useful to put or flag that some 'mandatory
> qualities' will or are considered by the group for what we're trying
> to achieve overtime and what we are not trying to achieve.

I agree with you, what can I cut out to put that stuff in? I've tried to
very aggressively cut the presentation down to the core material that
W3C members will need to make the decision.

> Things we want - Open-Standards Licensing (W3C Patent Pool
> considerations - ie: why W3C)

This is a core assumption, and I don't think it's necessary to mention
it (again, because of time, not because it's not true).

For example, we're not saying "we want to use web architecture
principles"... again, we're doing this at W3C and there is the TAG...
they will make sure we're doing that just like W3M and staff will make
sure we're doing licensing correctly.

> - To use Linked-Data

This would derail the conversation (it always does).

> Things we don't want: - We do seek to produce DRM for WWW.  (we
> believe in freedom of speech)

Another third rail at W3C :) - we don't need to say anything about DRM
and any mention of it could derail the conversation.

I'm sure you're getting the theme by this point. It's super easy for
these charter discussions to get derailed by any information that is not
directly related to the ask.

> - We do not seek to produce evidence systems that are designed to be 
> used in an asymmetrically bias way by entities.

If we say this, then the request from members is "prove to me, in a
convincing way, that the architecture that you're presenting can prevent
this from happening"... which is impossible to do because we're talking
about the ability to express information in a verifiable way, we're not
talking about the ability to express information in a morally just and
verifiable way.

> slide 12 - you don't say how many individuals support this work.
> W3C may not care, but i do, and i'm sure others do too. whether or
> not their actively participating - it's perhaps important to show
> they'll be acknowledged if they do.

W3C (and most of its members) care about individuals. Most individuals,
however, don't roll technology out to millions of people. W3C and many
of its members are conservative in this regard. They don't want to bet
on a Satoshi or Linus Torvalds to put something out there, they want to
have confirmation from ETS, Pearson, and Bloomberg that this stuff is
going to be deployed in a big way.

Many of the individuals that make this stuff happen are not
acknowledged. The large corporations take credit for making it happen
(after rebranding the technology as theirs, of course). It's not fair, I
don't think that's how it should happen, but that is definitely how it
happens today.

The issue w/ mentioning the individuals that have participated is that
the statement is ignored as unnecessary information by most W3C AC reps.

> Slide 13 - understanding it's a charter - i'm wondering how version 
> control might be inserted / adapted to the pitch.  Or is that done
> by stating 'verifiable claims' rather than something else that may
> denote the broader work carried out by the Creds CG overtime?

Hmm... I don't understand the question.

> Also - the group should IMHO make a recommendation for 'x' work
> (output of verifiable claims taskforce) to be progressed and
> therefore ('the ask') recommended by payments IG for xxx to be taken
> to vote for xx - blah....

Don't understand the suggestion.

Thanks for your thoughts Tim. Will keep them in the fore of my thinking
as I go back through the slide deck w/ everyone else's suggestions and
refine the pitch.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
JSON-LD Best Practice: Context Caching
https://manu.sporny.org/2016/json-ld-context-caching/
Received on Monday, 20 June 2016 00:37:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:29 UTC