Re: "Web Identity" -> "Web Credentials"

On 11 March 2014 02:43, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 03/05/2014 08:32 AM, Melvin Carvalho wrote:
> > The WebID XG has spent several years trying to come up with
> > definitions for similar concepts.  I would veer away from this
> > definition and have
> >
> > 1) an identifier that is a string that identifies an agent (person,
> > or corporation).  Formalize this e.g with ABNF
>
> The introduction isn't talking about the "identifier URL", it's talking
> about what a Linked Data identity is about. That said, "identifier URL"
> is bad, so it should be changed to something else. However, seeing as
> how the WebID spec already uses the term "WebID" in a way that is very
> narrow, we can't re-use that term in the Identity Credentials spec. More
> on this below...
>
> > 2) I would use the term Profile or Profile Document what what you
> > are calling "An Identity"
>
> We did at first, and then figured that it was a bad choice. Why have
> this distinction? Why are there two concepts for something that only
> needs one concept? Isn't the only terminology you need something like:
> "identity" and "identity URL"? Where "identity" is a set of statements
> about an entity and "identity URL" is the mechanism used to identify a
> particular identity? More below...
>
> > WebID A WebID is a URI with an HTTP or HTTPS scheme which denotes an
> > Agent (Person, Organization, Group, Device, etc.). For WebIDs with
> > fragment identifiers (e.g. #me), the URI without the fragment denotes
> > the Profile Document. For WebIDs without fragment identifiers an HTTP
> > request on the WebID /MUST/ return a 303 with a Location header URI
> > referring to the Profile Document.
>
> Reasons this is a bad definition:
>
> 1. An Agent is something that acts on behalf of another thing. What
> we're trying to describe here is an entity, not the agent. In other
> words, an "identity" is a super class of Agent.
>

Thanks for the explanation.

Loosely speaking, In Foaf you have a Person, and you have a the super class
which is an Agent which can be a robot, human, group or corporation.

The super class of Agent I think is a "Thing".

"Agent" itself is not tied to foaf in the Web Identity spec, it seems to be
more or less the same thing you are saying.

When you say the definition is too narrow, what type of things would be an
Identity and not an Agent?


> 2. The whole 303 thing is confusing and will be lost (and not
> implemented) by developers. The semantic web community really needs to
> drop the whole 303 redirection thing because it is too esoteric. I'd
> suggest going with something simpler like:
>

> "To make statements about the document at a particular URL, use the
> #__document pattern."
>
> or (and this is a bad idea, but better than 303s):
>
> "Statements about the document at a particular URL should associate an
> rdf:type of xyz:Document. Clients should be sure to never co-mingle
> statements about a document with any other sort of statement (in other
> words, enforce provenance for statements about a document)"
>
> What about this instead:
>
> "identity"
>   A set of information that can be used to identify a particular entity
>   such as a person, agent, or organization. An entity may have
>   multiple identities associated with it.
>
> "identity URL"
>   An identity URL consists of an HTTP or HTTPS scheme and denotes an
>   identity.
>
> "identity document" (don't know if this is necessary)
>   A document that exists at an identity URL and contains statements
>   about an identity.
>

May help with an example

I am a type of Person.  Which is a type of agent.  In your terminology am I
an Identity, I think not.  So what am I?

The digital string that "denotes" me on the web, is
http://melvincarvalho.com/#me

The (profile/identity) document which contains more information about me
can be dereferenced at http://melvincarvalho.com/ and specific statements
about me found at the #me anchor.

So I wonder is identity a super class of agent?

In the terminology above which is the Identity, the Identity URL and the
Identity Document?


>
> > WebID Profile or Profile Document A WebID Profile is an RDF document
> > which uniquely describes the Agent denoted by the WebID in relation
> > to that WebID. The server /MUST/ provide a |text/turtle| [turtle
> > <
> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html#bib-turtle
> >]
> >
> >
> representation of the requested profile. This document /MAY/ be
> > available in other RDF serialization formats, such as RDFa
> > [RDFA-CORE
> > <
> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html#bib-RDFA-CORE
> >],
> >
> >
> or [RDF-SYNTAX-GRAMMAR
> > <
> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html#bib-RDF-SYNTAX-GRAMMAR
> >]
> >
> >
> if so requested through content negotiation.
>
> There is no need for this definition and no need to tie it to an RDF
> serialization. Yes, JSON-LD can be translated into RDF, but it doesn't
> have to be. Don't provide so many choices and leave it up to content
> negotiation, while more flexible, that will ensure that there will be
> divergences in what people implement and thus the whole technology stack
> required to implement a working system will be more complicated as a
> result. For example - to implement what's described above, you'll need a
> TURTLE parser, an RDFa parser, and I presume a JSON-LD parser. What
> about a NQuads parser? Ntriples?
>
> The definition above would be better, leaving how to fetch the document
> and the format of the document up to the protocol.
>
> > Open Questions: 1) JSON LD as a serialization?
>
> Yep, there should only be one serialization in order to simplify
> consumers of the data.
>

>From my POV, I already implement turtle, but would not be a huge effort for
me to add json ld I think.


>
> > 2) mailto: URIs to be included in the definition?
>
> No, but you can use a mailto: in a credential such that discovery may
> still be performed via email address:
>

OK, so something like an IFP, that works I think.


>
>
> https://web-payments.org/specs/source/web-identity/#detailed-flow-for-credential-based-login
>
> We're currently working on a proposal such that domains that are not
> email providers may still vouch for an email address. So, for example,
> you could still login to a website using "melvin@gmail.com", but your
> personal website "http://melvincarvalho.com/" could still vouch for the
> email address.
>

Great.

So what about content addressable identifiers like bitcoin: addresses?


>
> We're currently looking into implementing this via a distributed data
> store potentially built on top of telehash, or some other sort of
> decentralized identity store. This approach would allow you to pick your
> identity provider independently of your email address /and/ not require
> the sort of centralized infrastructure that is required for Mozilla
> Persona. This approach might solve the "email provider buy-in" problem
> that Persona had.
>

Interesting idea ...

At this point I'm unsure DHT's give you anything the web doesnt!  I'm
convinced that decentralized systems can be built using the web, tho I've
yet to prove it!


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