Re: Web Identity specification and Social Web

On 3 March 2014 04:01, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 02/24/2014 09:57 AM, Melvin Carvalho wrote:
> > +1, although I don't think we need a spec to say: "An identity is
> > denoted via a URL".
> >
> > I think it's essential to define terms clearly.  Why would we not
> > want to use this definition, or do you have a better one?
>
> I agree. I never said it's not important to define terms clearly. I just
> think that we don't need an entire spec to define a term. :)
>
> >> 2. Web Identification -- this covers identity claims associated
> >> with a WebID (for instance) or other Identifiers (e.g., those
> >> supported by OAuth)
> >
> >> 3. Web Identification Verification -- this would be about
> >> protocols for verifying identity claims.
> >
> > I don't see much point in decoupling #2 and #3 other than design
> > purity.
> >
> > I think these elements need to be logically decoupled in a modular
> > way.
>
> +1, but they already are /logically/ decoupled, aren't they? What am I
> missing?
>
> > This way different mechanisms can be built together for identity,
> > verification and access control.  Defining a one size fits all
> > solution for identity is the road to hell, imho
>
> Yes, but there's never going to be a one size fits all solution. It's
> the Web, afterall. :)
>
> What we need to do is provide something that developers can sink their
> teeth into, and providing a large array of options from the beginning is
> a bad way to go. Choice is good, but it can also be crippling. This is
> one of the biggest problem w/ the Semantic Web, often new entrants are
> flattened by an ever increasing snowball of perfectly viable options.
>

I think this approach could work in many instances.  But, IMHO, finance is
just too large to have a definitive solution.  You need building bricks
that fit together that can be switched in and out based on the use cases.

By all means publish an *example* solution, for a developer audience, but I
think it needs to be modular.


>
> > How about reusing this work and building on it?
> >
> > https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html
>
> What parts should we re-use? What parts should be built on?
>
> > I think it would only need to be tweaked here and there.
>
> That's not as clear to me as it may be to you. The problem is that those
> specs are very broad. Implementing them requires quite a bit of work,
> and it's not clear how all of it fits together into a cohesive system.
> There are no test suites for those specs and very little
> implementations. I understand what each spec is attempting to
> accomplish, but trying to convey those principles to a Web developer
> that doesn't care about any of the grand design behind those specs is
> going to be difficult.
>

Fair point, but let's consider just the Identity spec.  A very short
concise spec explains what identity is, and what a profile is, with maybe
some examples and a simple test suite such as "vapour".


>
> Here's the issue: To build on top of those specs, we're going to have to
> effectively take those specs REC-track. Those specs have existed out
> there for some time w/o ever being taken REC-track. So, either someone
> else is going to take those specs to REC, or we (the Web Payments CG/WG)
> is going to have to do it. Selling a bunch of payments companies on
> taking those specs to REC is going to be far, far more difficult than
> picking the best pieces of each one of those specs and standardizing
> just the bits that get us to a solution that solves a concrete problem
> (like being able to write KYC information to a URL on the Web).
>

Makes sense


>
> If that first steps is successful, we can then bring the other
> mechanisms into the fold (formal definition of WebID, TURTLE, cert
> ontology, etc.).
>

IMHO, we dont need to touch the cert ontology, if that's going to be a
barrier.  But defining identity well is important, something where other
groups have not done well.  e.g. Persona dont use URIs, OpenID/OAuth didnt
use URIs for a long time (ie XRI dependencies) but now are more aligned to
mailto: and http: URIs.

To my mind the main difference between the work done in the WebID group and
the web payments identity spec is whether to use turtle vs json-ld vs rdfa
or a combination which which order of preference.  I think that's where the
contention lies ... but is it a reason to create a whole new spec?


>
> When I look at those specs, I just see a grand amount of work that will
> need to be done before we can move the spec we care about (Web Identity)
> forward. Even Web Identity is going to be a big effort and may well be a
> very hard sell to the payment companies and banks. We want to build on a
> solid foundation, and I don't currently see the stack you're pointing to
> as having the development backing to be solidly implemented and tested.
>
> I can be more specific by citing examples, if you'd like. :)
>

Yes this makes sense.  I just advocate reusing common language, themes etc.
to keep in line with the axioms of decentralization, modularity,
universality etc.


>
> > How you make a claim about an entity should probably be verifiable to
> > be useful to the Web platform. Having the former without the latter
> > is not very useful from a Web Payments perspective (and this is why
> > the badly named "Web Identity" spec includes both the expression and
> > protocol for modification of claims).
> >
> > Claims and the web are logically separate things.  Most claims
> > historically as signed on paper.  There does not need to be a tight
> > coupling.
>
> I'm not saying they're not logically separate, nor am I saying that
> there needs to be a tight coupling. I was saying that both are necessary
> for the system to be useful. :)
>

+1


>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Worlds First Web Payments Workshop
> http://www.w3.org/2013/10/payments/
>