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

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

From: Joseph Potvin <jpotvin@opman.ca>
Date: Wed, 12 Mar 2014 04:35:30 -0400
Message-ID: <CAKcXiSqwbhSzzdAwRuYE3i_GcXZO-6a=QSwT-uZNwHHeHpM0kg@mail.gmail.com>
To: Tim Holborn <timothy.holborn@gmail.com>
Cc: Web Payments CG <public-webpayments@w3.org>, Kingsley Idehen <kidehen@openlinksw.com>
Tim, Very interesting outline to aid thinking.

For anyone in need of a good headache, I'll add that there's a
requirement also to take into account some additional meta-layer
(a) the allocation of the right/responsibility to choose which aspects
of an agent's identity applies to any particular transaction;
(b) the allocation of the right/responsibility to choose which
jurisdiction's rules govern the allocation of the right/responsibility
to choose aspects of an agent's identity that shall apply to
transactions or things;
(c) the allocation of the right/responsibility to recognize, or to not
recognize, jurisdictions.

Layer (a) can be considered grounded in the originally French legal
concept of "droits morales"
http://www.artslaw.com.au/info-sheets/info-sheet/moral-rights/  (for
anyone who is not familiar with the terminology context, this is not
about "moral=ethical", it is about "morale=attitude" as in the phrase
"team morale"). ...though I'll bet it probably all traces back to
Aristotle!  Here's a summary in Australian (based on Brit) law:

Layer (a) in a web payments realm will include, say, the right to
determine whether one's trade is taxable or not (Are "you" or are
"you" not "in the business" of fixing bicycles for a living?)

Layer (b) has been playing out recently in relation to Bitcoin, which
is getting decided not at that realm, but via Layer (c).

Layer (c) is determined by legal/ethical "doctrine" or "principle".
For example, there's the "Principle of Paramountcy" (example, in
Canadian federalism
https://en.wikipedia.org/wiki/Paramountcy_%28Canada%29 ... sort of the
"I'm more comprehensive than you are" ethic). But there's also
"Principle of Subsidiarity"  (example in EU federalism
https://en.wikipedia.org/wiki/Subsidiarity  ...sort of the "I'm more
local than you are" ethic).

Damned "nested hierarchies"! http://www.isss.org/hierarchy.htm

Joseph Potvin

On Tue, Mar 11, 2014 at 11:54 PM, Tim Holborn <timothy.holborn@gmail.com> wrote:
> Morning / Afternoon All,
> from a lay-persons point of view; it appears there's about 3 constituents to
> WebIDl
> 1. An RDF Ontology (currently pointed at a current version of FOAF).
> 2. the use of URI's in the Subject Alternative Name Field (which then
> describes something in some "linked data" compliant manner)
> 3. the x.509 Certificate, and the manner in how it's been deployed.
> Herein; i share a few frustrations.
> My frustration with the ontological preference and vocab; is that when
> applying identity and use-cases to people and their activities; on Web
> functional concepts,
> 1. Describing a Person
> a. I doubt it's secure to describe myself (akin to a passport) in full in
> one FOAF document.
> b. The foaf method doesn't appear to understand 'things' very well; and the
> language of 'agent' is mixed between 'things' and 'legal entities' (whether
> person or incorporated legal entity).
> I have me;  I'm happily doing my thing in an array of different groups.
> Friends, Family, UNI, projects, etc.  I have two Facebook accounts, one does
> activism for social issues; the other is more personal.  I have a linkedin
> account with people i don't want on my Facebook accounts; and i've got an
> array of other web2 accounts (some i use, some - old IM accounts, forced
> upon me in new evolutions or left behind in history, without the logs /
> content).  Most people have probably lost data at some point, photos,
> documents; whether it be due to lightening or lost credentials; the issues
> are similar to those needed for commerce.
> Whilst the identity issue has been around for a longtime; it seems it's
> still knot solved.  the most difficult thing about crypto-currency (for
> example) is the wallet.  It's not like i want to participate in supporting
> another company to act on my behalf (because i'm not able to do it, or not
> entitled to do so); i rather like the ideas of democracy; and the
> socio-philosphical view that things invented by humans are there to support
> humanity, society, environment and the world around us.  So, internet
> identity at some stage needs to be extraordinarily accessible; as as much of
> a right for a person, as their ability to participate in civics / democracy,
> even if it's simply walking into a room, declaring their name and being
> afforded the right to vote.
> when things start to get more complicated; I'd like to lower the resolution
> of some results to some groups.  If i subscribe to junk mail, or share GPS
> tagged photos; i might not want to tell them my address, just the state or
> suburb (district?) i live in.  I can understand why it's good to have that
> data available; but not to everyone for every situation.  Therein; there's
> an array of implications surrounding the description of a person
> ("FOAF:PERSON") and my view has been that ideally; there's a way to author
> multiple FOAF files that link via subjects.
> an early (and very quick) mock-up
> http://mediaprophet.org/ux_KB/page4115292.html#0 attempted to explore this
> in a functional orientation.
> FOAF from what i can understand was essentially first developed to describe
> a person; but it's branched to be a way to identify an agent, and more
> complex descriptions than what was first envisaged for the ontology, many,
> many years ago...  Other issues with describing people include describing
> deceased people, for heritage applications (for example) and the ontology
> doesn't appear to handle these forms of descriptions of people very well
> either.  If a foaf profile is created for a deceased person - who is
> authorised to contribute to it.  How is that profile enabled to exist;
> whilst protected from spam.
> Then from the description of a person (RDF:function); the next constituent,
> starts to consider that everything on the Web should in theory have an
> identity; this is important for security, as if i loose my phone it's
> probably important to identify that a transaction was made by my phone and
> not by foaf:person.  Made by my phone on behalf of foaf:person makes more
> sense.
> The same concept applies to companies; where directors of a company have
> fiduciary duties to that company, the company is not capable of making its
> own decisions; and workers for that company have an array of expectations
> put upon them at different stages of the day, the role, etc.
> Tangentially; - linked to similar considerations; if a worker has a work
> laptop or device, and works on family stuff at home - is that foaf profile
> identified as an employee of a company and that profile is bound to a
> device; are they entitled to humanity, and identity independently if they
> use that device externally.  most people obtain mobile phones on
> telecommunications plans / contracts, as one potential example. the other
> of course relates to the cloud storage hosting provider of the data / data
> service.
> 2. Describing a legal entity
> legal entities are people and incorporated legal entities, in the eyes of
> most systems of law.   A person may execute a function on behalf of an
> incorporated legal entity or on behalf of themselves or someone for whom
> they are a carer.
> In my consideration, linguistically, these "roles" are not = agent. where
> agent may apply (in sociological / legal terms) are situations such as if i
> have a "role" as a real-estate agent; who has a contract (could be an
> e-contract) to sell that property (a thing) on behalf of someone else.  i
> believe there are implicit differences between the legal term 'agent' and
> the functional use of 'agent' in foaf.
> 3. describing things
> We've all got a web of things.  many want to decentralise and improve our
> influence over our own data (whilst seeking to broadly support & abide by
> the rules of our democracies / sovereignty, etc.).  Given we're moving
> towards an world of "linked data", to not acknowledge devices seems foolish.
> Web of Trust, Web of Thing, Internet of Things = yes, very confusing for a
> layperson at present.   At the end of the day, we'll be centralising info /
> data, not into a 'trustee' or "Social Network Silo" vendor situation (like
> web2); but rather to a place that we believe is safe for us to both retain
> ownership, privacy and other data related considerations; as well as enables
> us to share with more ease, accountably.
> Therein; much like we do today; we'll set preferences - Yes, i'm happy for
> RDF:ontology:label to person / ACL Group / et.al - to access x data assets
> from my LinkedData Cloud Storage place somewhere, without my explicit human
> intervention on a request basis.
> In my view; the permissions chain should acknowledge an array of devices
> (authentication chain?); and peoples association to those devices.   If it's
> a box at home, it's reasonable to assume the owner of that box has more
> control, that a shared hosting space somewhere in the world. if the chain is
> poorly executed; perhaps the reliability of the profile goes down - they're
> not capable of doing functions that have a requirement of high-level LOI [1]
> / EoI (evidence of identity) requirement; Equally, authentication chains
> might be established involving a multitude of ID's (people, companies,
> things...); or be functional, so a user could set-up some puzzle system where
> they needed to move their head in front of a camera, tap their phone with a
> card, then enter a passcode into a specific machine, and say a few magic
> words, within a pre-defined time-limit on a specified IP or subnet; - for
> example...
> If i want to set-up some complex auth chain for supporting specific
> functions, i should be able to. If i was executing an e-contract on
> something valuable, it would be important.  if i'm adding an acquaintance to
> an address book; well, i'd make it easy - press the button on my phone...
> This is not just important for my use specifically; but also in society;
> We'd likely want the trauma unit of a hospital to have access to the info
> they need to heal us; and, sharing digital receipt info to our accountant
> seems practical; but if we change accountants, we'd likely want to revoke
> access.  if a government employee is misappropriating actions that are
> harmful, perhaps we want a lawyer or our local political member of
> parliament to have a look at the data in full, and consider the claims, as
> groups / tagged using metadata perhaps.
> In theory; the difference between a digital key and a house key - is that a
> house key is physically programmed and doesn't support reprogramming very
> well.  We'll still need different keys, but the methods relate to identity,
> which is now described ontologically; and so, underlying all of this is
> seemingly the ontological issues, not particularly about the method.  The
> method of issues certs bound to a ontology, is dependant upon the ontology.
> I'd like to see the FOAF ontology improved, rather than replaced.  Perhaps
> this could be done with version control methods....
> the x.509 constituent is only one part of an authentication chain / cycle.
> To me it issues a certificate to a machine, which then identifies that
> machine as being "RDF Enabled" (or perhaps rather, the browser / IPv4/IPv6
> interfaces).
> I've got several certs in my system; and honestly, it's annoying.  I'm the
> only user on my machine; tried installing a cert at uni - active directory
> didn't really play well with the concept. i goto play with a RWW server and
> i've now got several certs to pick from, having to look at the URI's to
> figure out which one matches the location i'm trying to access.
> If a person (user / actor) is known to a machine - that should be easier to
> perform AUTH than someone who is new to a machine.  Importantly, a server in
> effect has a client/server relationship with other servers / services /
> infrastructure of legal entities.
> Whether the URI's listed in the x.509v3 certs are specifically FOAF or
> exclusively FOAF; is another issue again.   x.509v3 certs can have a
> multitude of URI's listed.
> Foaf spec is: http://xmlns.com/foaf/spec/
> Foaf Dev list: http://lists.foaf-project.org/mailman/listinfo/foaf-dev
> There's probably two fundamental groups; assets (things; computers,
> accounts, RFID tags, etc) and entities (legal entities (incorporated,
> natural)); and then fragmentation within those groups and subgroups.
> If there's an entirely distributed method to store the 'root' identifier for
> a person (similar to trying to prevent an foaf:agent from taking someones
> 'passport') that would be good, but in any case; i'm not the machine /
> account on a web server somewhere; i'm not a RFID enabled phone or tag; i'm
> not my computer.  I'd like to use these systems in a syndicated methodology
> to build out systems that are more relevant to me, than those who would like
> to use me for financial gain (i.e.: becoming an advertiser), as an entire
> embodiment for any particular request..
> explaining a solution that is not documented and well understood by
> specification related resources; will likely be troublesome.  in simpler
> parts of the planet it's difficult to know whether to follow
> http://www.w3schools.com/ or http://validator.w3.org/ but therein is the
> ideological concept; which perhaps it's not our role to define, but rather
> define an inclusive method that supports the differences.
> i think the use of people for financial gain should be opt-in. I've got a
> range of views / ideas, that are my own; not the only way of doing things,
> and i grew-up using english to communicate so i'm kinda affectionate to its
> traditions of syntax.   Spice traders didn't all speak the same language,
> although i'm rather sure they still had an interest in the semantics of
> language.
> In summary; i think the important part is actually on the RDF/FOAF end.
> forming a common set of values that can be used in a common way,
> respectfully.  I also think it's extremely important that people obtain a
> digital identity; i believe underlying all the problems, the average person
> does not have a secure online identity in any manner that would be deemed
> appropriate for an organisation functioning / exposed / operating with web
> systems, and of course - this is a multi-faceted issue.  x.509v3 elements /
> WebID is a step in the right direction, IMHO.  however, the ontological
> prescription does trouble me.
> Sociologically; there's a concept called shared values. if the models right,
> and the language used doesn't have a predetermined (inappropriate)
> common-law / legal meaning, i imagine it's highly scalable.
> Hope theres a contribution in said text; and i hope something therein makes
> some sense - thanks for listening.
> Tim Holborn.
> [1] http://en.wikipedia.org/wiki/Levels_of_Identity_Security
> On 12 Mar 2014, at 9:30 am, 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
> <https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html#bib-RDFA-CORE>],
> <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 08:36:19 UTC

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