Re: Verifiable Claims WG Proposal (presentation)

HI Manu,

Firstly i want to note that what is likely to be progressed here is
'verifiable claims' not identity from a baseline ID/AUTH perspective. I
think this distinction is important when considering what we are asking
others to help us standardise via W3C in relation to this body of work and
the current request relating to this document.

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

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

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.   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.

FWIW - i really dislike the idea of a block-chain managing ID/AUTH.  I
think it'll be a 'sexy' idea for about 3-5 years, but the implication is
likely to be in-place until quantum computing changes the way 'web'
software architecture is defined for the next 80 years.  I also think it'll
take about 10 years for people to understand Linked-Data/AI impacts on the
network, but that's not something we should exploit unfairly.



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.

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...?)

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.  Description could be identity timeline.   I also think it might
be worthwhile to consider notating somehow, how the target has developed
overtime.  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 other issue therein
this may help capture, is that the documentation references overtime use
various language and use-cases which may confuse stakeholders about what
they're buying into for this next stage.

In-turn, what i'm suggesting is to try to show that the work has developed
over a long period of time and the next step is... (in-turn relating to the
'ask').

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.

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).

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.

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.

ie:

Things we want
- Open-Standards Licensing (W3C Patent Pool considerations - ie: why W3C)
- To use Linked-Data

Things we don't want:
- We do seek to produce DRM for WWW.  (we believe in freedom of speech)
- We do not seek to produce evidence systems that are designed to be used
in an asymmetrically bias way by entities.

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.

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?

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....

Cheers,

Timothy Holborn


On Sun, 19 Jun 2016 at 04:20 Manu Sporny <msporny@digitalbazaar.com> wrote:

> Hi all,
>
> Here is the Verifiable Claims Working Group Proposal presentation for
> the Web Payments IG face-to-face meeting on July 1st 2016 at MIT.
>
>
> https://docs.google.com/presentation/d/1mL0MsPpdxdKiYFWVIyGVOFzypBsjylxepACN2MYw-yg/edit?usp=sharing
>
> Commenting is turned on, please leave questions/comments in the
> presentation if you can.
>
> I have also attached a PDF for those that can't access Google Docs.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Web Browser API Incubation Anti-Pattern
> http://manu.sporny.org/2016/browser-api-incubation-antipattern/
>