Re: Proof of Concept: Identity Credentials Login

On 17 June 2014 03:30, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 06/16/2014 04:09 PM, Melvin Carvalho wrote:
> > On 16 June 2014 17:50, Dave Longley <dlongley@digitalbazaar.com A
> > system that does everything WebID+TLS does *and* doesn't require
> > browser implementations (to become a popular success) is more
> > loosely coupled and has less prejudice, IMO. That's the system we're
> > supporting as an alternative to WebID+TLS. Concepts from WebID (not
> > WebID+TLS) are included in this alternative, because they don't
> > suffer from the same issues (tight-coupling w/browser UIs) that
> > WebID+TLS does.
> >
> > You seem to be betting your company on JSON LD vs Turtle, rather
> > than allowing both.
>
> I don't think anyone said that both aren't allowed. You MUST support
> JSON-LD... you MAY also support TURTLE. It's the Web - you can content
> negotiate.
>
> We (Digital Bazaar) don't plan to support /both/ JSON-LD and TURTLE in
> the beginning because the addition of TURTLE doesn't really add any
> advantage to the system. If others start deploying successful commercial
> systems that content negotiate for TURTLE, I'm sure we'd follow suit.
> Adding features increases complexity. Adding features that don't provide
> new capabilities seems like bad design.
>
> > It's a strange bet in that given that you've already written
> > canonicalization algorithms that change JSON into ntriples, which are
> > a form of turtle, I didnt expect it would be a huge undertaking.
>
> The canonicalization algorithms don't use N-Triples, they use N-Quads.
> This highlights another reason we didn't want to support TURTLE: it
> doesn't support graph labels (while JSON-LD does).
>
> We did consider N-Triples and TURTLE for the JSON-LD graph
> canonicalization algorithms and decided not to use either because
> neither provided the flexibility and scalability necessary to do proper
> digital signatures on graphs.
>

Oh, I see what you mean.  But the 4th element in the quad would then be the
URL, I think.


>
> > So now we have a fractured identity space for the moment, the digital
> > bazaar version and the WebID version.  It's a pity, but I guess
> > that's just what happens when people take views.  It's a bet that
> > could work out, imho.
>
> The fractured identity space consists of more than just those two
> technology stacks. It also consists of Facebook Connect, OpenID Connect,
> G+ login, OpenID 1.0, LTI, SAML, etc.
>

Facebook serve turtle :)

OpenID started out in the first version (Yadis) using Linked data, but they
changed direction in later versions

I was just referring to those systems using Linked Data, which from what I
can see are Facebook, WebID, Identity Credentials, and maybe some elements
of OAuth.  OAuth supports the use of URLs.


>
> > However I've yet to see a profile that is 5 star linked data.  That
> > imho is betting against awww, which is almost certain to be a losing
> > bet.
>
> Why do you think that the Identity Credentials spec proposes something
> that isn't 5 star Linked Data?
>

Well, this is just from having played around with it a bit and looking at
the serializations.  If I had a chance to see a live profile, I'd be able
to check, or run it through a validator, such as vapour.


>
> > I'd definitely like to reuse parts of the technology here, but I'm
> > currently sceptical that this identity solution will scale.
>
> What are the scalability issues?
>

Just a suspicion at this point.  Scalability would come into play if it
doesnt pass 5 star linked data validation, because then interoperability
can break with existing tooling, perhaps even allowing money to get lost.


>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Marathonic Dawn of Web Payments
> http://manu.sporny.org/2014/dawn-of-web-payments/
>
>