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

On 3/11/14 8:05 PM, Joseph Potvin wrote:
> 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?

You have to separate concerns:

1. identity
2. identifiers
3. identification
4. authentication
5. trust .

1-5 exist irrespective of document content format in regards to #3 (the 
identity card or profile document). The entity relation semantics 
expressed in an XrML document's content are distinct from the syntax 
used to markup said content. This is the point that's lead to so much 
confusion and eternal battles at the markup level.

As for UUIDs, the issue isn't uniqueness, its about resolvability i.e., 
the use of identifiers that provide denotation uniqueness and reference 
to descriptions, implicitly, which is what the architecture of the world 
wide web (AWWW) puts on a platter, for everyone to exploit.

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


-- 

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