W3C home > Mailing lists > Public > public-webpayments@w3.org > March 2014

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

From: Joseph Potvin <jpotvin@opman.ca>
Date: Tue, 11 Mar 2014 20:05:41 -0400
Message-ID: <CAKcXiSqd6WaSLnMTY3C95P3gBUwZAwd0OE5zw7HfNwua6imz5g@mail.gmail.com>
To: Kingsley Idehen <kidehen@openlinksw.com>
Cc: Web Payments CG <public-webpayments@w3.org>
Is this useful?
GeoHash and UUID Identifier for Multi-Agent Systems
http://link.springer.com/chapter/10.1007%2F978-3-642-30947-2_33

Regarding credentials of agents, this seems to be their attributed
package of rights+responsibilities, no?  Does XrML have anything to
offer there?

Joseph

On Tue, Mar 11, 2014 at 6:30 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> On 3/10/14 9:43 PM, Manu Sporny 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...
>
>
> An Identifier is a token that denotes (names, refers to, signifies) a
> referent. It's a critical artifact for enabling identification.
>
>>
>>> 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...
>
>
> Identification is what you get when you construct the description of an
> entity via the following:
>
> 1. an identifier
> 2. attribute=value pairs that coalesce around an identifier.
>
> Net effect, you have a description of the entity denoted by an identifier.
> Live examples:
>
> 1. Passport -- passport number is the identifier around which the claims in
> the document coalesce
> 2. Drivers License -- diver's license number is the identifier around which
> the claims in the document coalesce.
>
>
>>
>>> 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.
>
>
> A WebID is an identifier, in the form of an HTTP URI, that denotes an Agent.
> It isn't the Agent. It isn't a protocol. It is simply an HTTP URI that
> offers denotation, like any other HTTP URI, but specifically scoped to
> agents.
>
> Note, HTTP URLs are just HTTP URIs scoped to documents.
>
>> 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."
>
>
> No, folks need to step back, chill out, accept their narratives where
> utterly broken, and fix the poor narratives that have messed up most routes
> to comprehension.
>
> The whole 303 indirection matter is a consequence of trying to use HTTP URLs
> where you have WebIDs i.e., trying to use an HTTP URL (without a hash) to
> denote an Agent or any other entity that isn't a Web Document.
>
> This is such a trumped up distraction its untrue.
>
>>
>> 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)"
>
>
> That's early Gobbledegook from a narrative attempting to tell a story in the
> worst possible way.
>
>>
>> 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.
>
>
> That's identification.
>>
>>
>> "identity URL"
>>    An identity URL consists of an HTTP or HTTPS scheme and denotes an
>>    identity.
>
>
> No an HTTP URI denotes (refers to, signifies, or names).
>
>>
>> "identity document" (don't know if this is necessary)
>>    A document that exists at an identity URL and contains statements
>>    about an identity.
>
>
> That's identification via claims in a document about what denoted by an
> Identifier.
>
>>
>>> 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.
>
>
> No, when you use HTTP URIs to denote entities you end up with identifiers
> that resolve to (or reference) descriptions of their referents. We have a
> real-world example of this i.e., the different between a word and a term. A
> term has the dual qualities of denotation and description reference. A word
> only denotes.
>
>
>>
>> There is no need for this definition and no need to tie it to an RDF
>> serialization.
>
>
> RDF too is an eternal distraction, in that pushing it forcefully without
> coherent justification simply infuriates people. RDF has its unique virtues
> that manifest when positioned appropriately.
>
> So far, we have identifiers and identification. Now, to make identification
> discernible and comprehensible to both humans and machines, we need to be
> able to create the the aforementioned attribute=value pairs, that coalesce
> around an identifier, using an abstract syntax -- one that's brings us close
> to what we use in the real-world, when constructing sentences and statements
> i.e, the subject, predicate, object structure which every literate person
> possess some comprehension of, in their native language.
>
> RDF's abstract syntax is the same subject, predicate, object structure from
> natural language. The subject, predicate, and object components represent
> entity relationship roles where the participants are denoted using IRIs.
> Now, if you move this up a notch to Linked Data principles, instead of IRIs,
> we specifically use HTTP URIs so that we end up with terms instead of words
> i.e., we make statements instead of sentences. The meaning of every subject,
> predicate, and object (even when this is a typed or untyped literal) is
> de-referencable from the identifier used to denote each relationship
> participant, as represented by the subject, predicate, object abstract
> syntax.
>
> Hopefully, now that we are done with the abstract, we then have to make our
> identification reusable which requires the durability of a document and the
> dexterity delivered by representation formats. Basically, this is where
> RDF's so-called "concrete syntaxes" come into play i.e., you can persist
> those subject, predicate, and object based statements to:
>
> 1. paper ;
> 2. computer file ;
>
> using a variety of notations. Just like the real-world where English,
> Chinese, French etc.. are for all intents and purposes, just notations.
>
>> 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?
>
>
> Only when we stop these kinds of debates will we truly make progress. These
> debates about notations are so broken and distracting, its untrue. Let's
> stop wasting precious time on these distractions. On the Web you can
> negotiate the representation of structured data.
>
>>
>> The definition above would be better, leaving how to fetch the document
>> and the format of the document up to the protocol.
>
>
> We just need to accept that:
>
> 1. a WebID is an Identifier
> 2. a WebID isn't a protocol
> 3. a WebID is identification and authentication protocol agnostic.
>
>>
>>> Open Questions: 1) JSON LD as a serialization?
>>
>> Yep, there should only be one serialization in order to simplify
>> consumers of the data.
>
>
> NO!
>
> Do we have one language spoken by all human beings?
>
>>
>>> 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
>
>
> An Email Address is what is claims to be: a URI that denotes the location of
> a mailbox. Of course, the mailbox itself could be associated with another
> entity (e.g., its owner) via a relation. That's it.
>
>>
>> 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.
>
>
> You are mentioning too many MUSTs that utterly break the concepts that
> underlie the kind of open architecture that AWWW puts on a platter.
>
>
>> 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.
>
>
> Persona is a living example of everything I am trying to warn against. It
> was broken at inception, for the same reasons: leaky abstraction and failure
> to accept what AWWW puts on a platter.
>
>
>>
>> -- manu
>>
>
> Links:
>
> [1] http://slidesha.re/1epEyZ1 -- Understanding Data (this presentation
> covers most of what I've typed in haste in this post re. structured data and
> RDF)
> [2] http://bit.ly/1cchBvV -- Glossary of Terms .
>
> --
>
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter Profile: https://twitter.com/kidehen
> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>
>
Received on Wednesday, 12 March 2014 00:06:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:28 UTC