Re: Web Identity specification and Social Web

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.

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

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

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

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

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

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

Received on Monday, 3 March 2014 03:02:28 UTC