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

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

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

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

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.

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.

-- 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 Tuesday, 11 March 2014 01:44:15 UTC