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

IDENTITY / RASPS CONCEPT INTRODUCTION - Re: VOTE: Revised Identity Web Payments Workshop Use Cases

From: Tim Holborn <timothy.holborn@gmail.com>
Date: Wed, 16 Jul 2014 16:25:02 +1000
Cc: Web Payments CG <public-webpayments@w3.org>
Message-Id: <C41297FF-8291-4648-A540-BD2623549015@gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Hi Manu / CG Members,

apologies for missing the teleconf.  I’ve been a bit derailed by the very significant amount of interest i’ve received, and lack of clearly available solutions - within the area i’m now going to attempt, to summarise, as a report style - please give me your consideration - request…

SO, I’ve been studying the identity related implications, considering some of the broader identity problems (whilst i also want to make clear, that the demo produced recently was an excellent step forward, and something that should / could be built upon…).

RESEARCH -  RASPS

At the current stage of ‘brain-storming’ i’ve identified a number of qualities in relation to data, that is important to consider and/or potentially support.  

Privacy legislation exists throughout many parts of the world (at a minimum) and as new laws are passed, systems often need to support these changes which incurs costs upon business in maintaining compliance with relevant legal precedent / requirements.  This is one of many potential areas in which this field of work may benefit users.

The particular facets with regard to (identity)data policy frameworks; seem to be reasonably condensed down to the following factors,

Data:Reuse
Data:Accessibility
Data:Security
Data:Privacy
Data:Sovereignty 

(I’ve then put some letters through a scrabble word finder, to come-up with the term ‘RASPS’ - so therefore - Data:Rasps)

An ontology could be defined that can support RDF / LD Tagging of data-communications with properties relating to the areas mentioned above.  I note that TimBL’s FOAF File http://dig.csail.mit.edu/2008/webdav/timbl/foaf.rdf incorporates a CC:License. yet my conversations with different participants of CC, seemed to back-up my concern that CC is orientated for more traditional circumstances involving ‘content’, rather than ‘data’ or ‘personal information’, which is the more particular field we’re working with, in relation to identity.  I have found a number of other approaches, the Respect My Privacy work in particular http://dspace.mit.edu/handle/1721.1/53125 - and whilst it seems that the consideration has certainly been considered before http://wiki.creativecommons.org/CC-inspired_projects_for_Terms_of_Service_and_Privacy_policies - I haven’t found anything i can simply recommend to be included in this Web-Payments Spec, as ‘the solution’...

A CREATIVE COMMONS APPROACH?
My functional attitude was that we should be able to create something like ‘creative commons’ for privacy, which has then been extended to other data-properties.  Developing a ‘creative commons’ like approach, which would enable a user to be presented with a form consistent, or as accessible for users as something like: http://creativecommons.org/choose/  (understanding RDF:CC is a constituent of the usefulness) - whereby the attempt in terms of specification, is not to create standardised privacy or related policy documentation for the merchant / provider of a website - but rather for it’s users, so that the user can easily declare a form of ‘license’ for use of their information; which in-turn the site would be obligated to bind themselves to, should they seek to maintain a trusted relationship with others.  

Similarly; an email client might use a standard with these forms of declarations, to specify whether an email can be forwarded, retransmitted to other parties - or is solely intended for review by the recipient, or ‘identity card’ holder.  

DECENTRALISED
If a system were created which required you to create an account, in-order to ‘manage’ your ‘RASPS’ settings / usability, then this account structure would in-turn become the weak point.  As a method to describe ‘data-rights’ or license by end-users to websites, the website aggregating all of that information would in-fact, potentially, become a bigger threat than the privacy issues with institutionally fragmented - identity storage sites, including but not exclusive to social-netork silo’s, etc.. 

therefore; it seems reasonable that any well considered method of dealing with RASPS issues - would use Linked-Data and support CloudStorage / Read-Write Web like Functionality (basically, make it decentralised.).  So long as an ontology is used, fragmenting the storage should be capable from a persona / credentials - identity service provider basis. 

SCOPE
It appears that ‘critical path’ needs to be define, in-line with properly investigating the potential scope.  The underlying concept is that identity related data (i.e. inclusive of sensor data, attached to an identity) is actually valuable, perhaps best described as a form of ‘knowledge capital’.  Should a 3rd party obtain wilfully, permission to use that data for specified purpose - it becomes valuable.  Should a party require information, the results can becomes unreliable and in the case of law-enforcement, needs to be verified.

When looking at the use of data, for commercial purpose - perhaps a good example is loyalty relationships.

If i could tap my phone, NFC Card or some thing - to obtain a digital receipt for a purchase, which i could then in-turn leverage to form a loyalty relationship with a merchant - especially if i don’t need to carry some card - and - be able to manage that relationship within my own environment - well, that would be really useful. Especially with small businesses, and i’d also remark - for tourist destinations and small towns, where an operator might have a higher price to take advantage of a tourist season, but it poorly affects the much lesser paid locals, who are also affected by the price differences. 

In addition; a tourist might see something they like - and these technologies / products in future might offer more people, the opportunity to simply ‘tag’ that operator and product, and go to them online to seek purchase after they’ve returned on holiday.  

I’ve also been ‘testing’ (like a 'method actor') how a loyalty program works within a major supermarket chain.  I don’t like joining their loyalty project, for a range of reasons, but if i don’t join - then i don’t know what the price of a product is, as they’ve got ‘specials’ which intrinsically require you to ‘swipe’ a loyalty card. Apparently those price-tickets have a different colour, but it’s not so important to me that i want to remember the tag colour when evaluating which product i want to purchase, etc.  So; i’ve taken to asking for a new loyalty card each time i’ve gone through the check-out.  I then get the discount, and dispose of the pamphlet. An employee of the company introduced me to this concept, and i’ve found it works quite well, having saved a sizeable amount of money in the practice of using this operational approach.  Ideally, some homeless person could obtain a loyalty card, and other members of the public willing to provide help for someone less fortunate - could then get the ‘loyalty maid’ (like a meter maid, but different) each-time someone wants their loyalty discount. The homeless/loyalty person could come, swipe the card - i get the discount, they get the loyalty benefit, Perhaps after a couple of months they could collect enough ‘loyalty’ to go overseas, to some nicer place, and start again…- everyone wins (except perhaps, for the analytics engineer and their marketing geared associates)...  

So; it seems to me, that the capacity to respect a persons identity - is as important as defining it, and supporting relevant accountability measures as required my law, and as otherwise deemed beneficial, in the interests of good-commerce.  

LINKAGE TO WEBPAYMENTS - CG / IDENTITY WORK
I think, it is not reasonably plausible to dislocate the two areas of work.  Therefore i’ve felt both the duty to follow-up, spend the time to focus and look into these facets of data-policy in relation to the Web-Payments works - and, write this rather extensive email to you about it. 

It is plausible that it’s simply forgotten about or put ‘out of scope’; yet reasonably, i think given the timeline for this work is a couple of years - i’d argue your going to have to deal with it someone, in anycase.  Beyond that, by considering these aspects to data-policy, you should be able to immeasurably improve your considerations around how the relationship / identity / loyalty systems could work, in a way that respects the interests of users. 

Reasonably however; the scope is potentially substantive enough, as to warrant the development of a solution external to the web-payments group.  yet, the WWW technical experts within the field - are perhaps within the group, so, i’ve not found an answer to whether this area of research falls within scope or out of scope, for important things to consider by web-payment participants overall.

in relation to ‘links’ i’ve set-up a ‘channel’ on cimba.co under ‘timothy Charles holborn’, therein - ‘privacyResources’, where i’ve been posting links and web-resources i’ve found through this initial stage of researching the field broadly.  I note, the application - Cimba.co is an example of a RWW application, where the cloud-storage mechanisms are described http://myprofile-project.org/thesis/manuscript_en.pdf - another form / similar product can be found http://demo.openlinksw.com/ods/ 

PRACTICAL DEFINITIONS?
It seems to me; we’ve got two layers of identity.  The underlying, or foundation layer - has a prerequisite of supporting KYC / AML - and related (‘Law Enforcement’) requirements.  These properties do not extend necessarily, to the desires of other actors / agents. 

It’s my view; that we’ve actually got two elements within this identity spec.  One area maintains compliance with KYC / AML (credentials), the other is ‘Persona’ based (FOAF>?) and is privately attached to the Credentials.  

In practical terms this might be akin to purchasing a domain, and a hosting service.  These two services combined represent the credentials or the capacity to facilitate the credential.  

In this conceptual example; the ‘identity platform’ then has application layers - A wordpress like site, something that might stores my receipts, acts as my loyalty brochure browser, perhaps a few FOAF files - ‘gamer me’, W3 Me, etc..  

If the domain model is used and i wanted to enhance my privacy for a particular purpose; perhaps I could create an agreement between my ‘identity service’ and a secondary intermediary or arbitrator - who can provide anonymity services - yet within their systems are private links, that can support KYC/AML should it be required by law. 

Persona enables privacy, which can be a persona / or username:  

If you want to buy a toothbrush, i doubt the merchant needs to know your medical history.  in fact, they probably don’t even need to know your name - they just want to prove, they’ve sold you a toothbrush - which was shipped to you - delivered by a courier to the correct address on x day, received by x person - signature acquired (by courier). or not.  could just be posted.  Law-Enforcement may get involved however - for whatever the unknown reason be (from the persona point of view); so, if the funds were stolen, and the police are investigating - they probably need to know that the stolen funds were used to purchase that toothbrush; but whether he said he used a valid payment method vs. whether he centralised his identity as to maintain compliance, and exposure - as a named entity - well… that’s unnecessary for the purpose of purchasing a tooth brush (other than perhaps, the requirements for shipping.)

regardless of the ‘good standing’ of the customer; the toothbrush needs to be paid for, and delivered.  If the customer seeks to be identified as the same person upon their next visit - they might get more information about buying the same toothbrush they liked, again.  If not - well, they won’t. 


EXAMPLE / OUTCOME - Digital / Physical enablement.  

An array of use-cases will require some form of printed output. With regard to requirements for shipping - perhaps some sort of encoding for packaging that links to a purchase URI might enhance support for privacy.  That way i could label, to the merchant, ‘this is my toothbrush’ in the field that says ’name’; , which could in-turn be put on the sticker - yet if, for law-enforcement purposes they need to identify my ‘credentials’ that ‘persona’ announcement could in-turn be linked back to my identity for fiduciary purposes, or perhaps they’ve also sent some dangerous toothpaste with the toothbrush and that needs to be sorted out somehow, including whether or not it was purchased - or sent / packaged without request…

Recently i went to a Bitcoin conference. When registering, i was REQUIRED to enter a company name and my role; so i put ‘natural legal entity’ and ‘self’.  next time, i’m thinking FOAF:AGENT or indeed ‘CommonWealth of Australia’ / role ‘Citizen’.

To summarise; I’m thinking the identity structures could perhaps be reviewed.  Linked-Data / GraphDB’s / an RDF enabled WWW - has different qualities to that of the early 00’s, when macromedia flash started being capable of communicating with databases (as an incremental example), which in-turn was different to the perceived threats of telephone books being published and misused, junk-mail became a popular direct marketing method, the VCR based Video Camera became a threat to the privacy of neighbours and whatever strange habits they may have that the ‘funniest home video’ show would love to air.., etc. 

The identity problem is rather extensive, yet - I believe it is a highly important area which can bring great meaning to the WebPayments initiative more broadly, with special consideration for decentralisation, connectivity between traditional POS and WWW systems and an array of fields or areas that could very much benefit from a well-defined W3C Electronic Commerce (and Identity) specification.  WebID is another group highly involved in the field of Identity, yet the current specification is perhaps overly narrow. Identity Work Fragmentation seems to poorly support useful output.  So, as much as anyone - i’m seeking to fully consider the options, and obtain support in doing it.

Perhaps the way forward is to consider how other Linked-Data Identity related systems sh/(c)ould work, define the web-payment requirements, and see whether we could / should form a system for enhancing support and definition more broadly, than simply the needs of WebPayments specifically.

In Considering ‘data privacy’ / ‘data rights’, i’ve spoken to an array of Australian Organisations in the field, and they’ve been extremely supportive.  I feel should the group form the opinion that participating in the development of this field of work - in relation to identity requirements - be in the interest, and critical path of defining the Web-Payments Spec - It may be well received broadly by the community, which in-turn may provide further support to the standards work overall.  It appears the people most interested in the field of ‘privacy’ and ‘data rights’ are lawyers, and activists (of one form or another), these groups could be well-paired with the Software Evangelists and commercial (or state) influencers, who may be more technically savvy, commonly seeking to define a solution that is more useful than what the market has to offer at present.

Whilst i’ve certainly conceptualised web-payment systems, supportive of individuals, and economics of production in a horizontal and vertically scalable manner (exploiting Reuse capabilities for identity tagged work, with - web credits functionality (for example); I feel my exploration into the privacy issues has been enormously worthwhile, very highly received by others and well worth exploring further, in relation to Linked-Data, Identity and of course - web-payments.

I hope i might find some others who share an interest for the field of work / study, and from Manu’s perspective - can you give me some guidance around how this field of work, might best work with the WebPayments undertaking.

In relation to the below use-cases,  I’ve iteratively responded below (surrounding my considerations atm). 

I’m thinking we should reform the structure; separating the ‘identity requirements’ in terms of ‘credentials’ and ‘persona’, whilst adding a ‘data-rights’ language, which in-turn recognises that ‘data’ (personal information / metadata / sensor data / etc.) can be an economic asset / influencer; and that the user should, in relation to the service qualities of an identity provider, be capable of selecting requests in relation to data-use, by a recipient or requestor.

I also note; that identity services that use a recovery system linking back simply to an email-address…  Well, the identity requirements or perhaps ‘solution’ is an area that is both expansive, and in dire need of innovation / focus.  If we’re bridging organisations who are authorised to hold data we’re capable of legitimately using as ‘credentials’, then we shouldn’t need to use a traditional email address...  

TimH.

On 16 Jul 2014, at 11:29 am, Manu Sporny <msporny@digitalbazaar.com> wrote:

> Please +1/+0/-1 each identity use case below in order to show whether or
> not you agree that we should try and attempt addressing the use case in
> the first iteration of the Web Payments work. If you +0 or -1 the use
> case, please specify why as well as changes that could be made that
> would result in you +1'ing the use case.
> 
> ----------------------------------------------------------------------
> 
> Use Case: Store basic identity credentials and payment provider
> information on the Web in a way that is easy to share with various
> merchants given authorization by the owner of the identity, and that is
> easy to synchronize between devices.

‘credentials’ are different to ‘persona’ -  yet they need to be ‘privately’ linked. 

Sovereignty of data, or Country Code of ‘owner’ might also be useful?

Language?

‘Legal Entity’ = Natural or incorporated Legal Entity; who is validated with Identity Credentials, which may be ‘linked’ to ‘persona’ for the purpose of developing and/or maintaining relationships with merchants. 

This use-case also considers storage / accessibility of identity information, as an additional constituent to the creation of it.  

> Notes: This includes the ability for the identity owner to manage the
> identity information. It does not include the ability for the identity
> owner to automatically sell their identity information.
> 
NOTE: I think we need to work on the identity structure. 

> Use Case: A customer visits a website and authorizes the transmission of
> one or more pieces of information (such as proof-of-age, shipping
> address, etc.) previously stored with an identity provider to the
> website to enable access or fulfillment of a transaction.
> 

I’m not sure that needs to be carried out.  If ‘trust’ is established between a service provider supporting the ‘identity credientials’ of a ‘legal entity’, customer, then in theory the website simply needs to go ‘ask’ is FOAF:Agent:Person: Name ‘gamer raider’ - 18+?

The identity credentials provider can simply provide an approve / deny.

> Use Case: Using metadata that is the result of a transaction, discover
> attributes associated with the identity of participants in the transaction.
> 
In theory - the metadata / URI could be trackable throughout the lifecycle of the product / delivery / warranty.  I’m not sure it needs to ‘identify’ the ‘credentials’ by all participants - or simply the participating persona. 

> Use Case: Digitally verifiable credentials such that a merchant and
> payment processor in a transaction can prove that they have done due
> diligence in verifying the customer's identity (KYC).

KYC is required in certain circumstances for some purposes.  You goto the petrol station, buy some milk, they’ve got a camera on premises, they’re card-processor requires you to fill in your details - but you don’t need to establish a relationship with the retailer, unless you want to…

Yet equally; pharmacy require proof that someone is someone in particular in relation, to a script, that also needs to be verified.  So.

In theory perhaps; we’ve got different levels. 

Some merchants will require KYC like functionality; others will not. 

Whoever is holding or maintaining the identity credentials, which pursuant to my view - would be the foundation for any persona used - would need to support the needs of a variety of different forms of merchants. 

Perhaps for specialised purpose; specialised identity credential providers may exist. (Military systems, etc.). 

Can one ‘identity credentials’ provider automatically (link) with other ‘identity credential’ accounts - should they believe the accounts are held by the same identity? 

how are identity credential providers made discoverable? 


> 
> Use Case: A customer executes a transaction without revealing secrets
> that are not vital to the transaction (i.e. identity, passwords, PINs or
> other information that the merchant does not need to know).
> 
i’m not sure the term secret is best.  It might simply be a preference. 

I prefer to be called ‘tim’ rather than ‘timothy’, and often have ‘timothy holborn’ on identity documents, not ‘timothy charles holborn’; and depending on the type of document, i’ll care more / less.  a yacht-club membership would be more personable if it said ‘Tim Holborn’; a drivers license would be more legitimate if it said ‘Timothy Charles Holborn’; and i’ve met another Tim Holborn - who’s in the US i think? nice guy - but i’m not him.

I’m therefore thinking use case might say

‘A customer execute a transaction whilst personalising any loyalty information required by the merchant’

> Use Case: Use an existing, widely deployed identity provider mechanism
> (i.e. OpenID Connect) to integrate with the digital credentials sharing
> and payments initiation process.

To authorise a pre-existing Identity Provider Mechanism (i.e.: OpenID Connect) to support authentication requirements in connection to a merchant.

NOTE: The identity provider, will have very clear requirements surrounding ‘identity credentials’ which cannot be deferred to some 3rd party via back-channel.  Therein, much like the authorisation process for other ‘identity credentials’ and ‘persona’ instruments, any Authentication solution would need to be ‘validated’ in a similar way, by the ‘identity service provider’ (or ‘knowledge bank’, depending on your views)

> 
> Use Case: Transact with a merchant without revealing any identifying
> information. Identifying information is available to the payment processor.
> 
If the language used split ‘persona’ with ‘credentials’, then it may read better.  We’ll always have ‘identifiers’, but perhaps we can assert expectations or a request statement; around how we seek 3rd parties to interact with whatever they get, through whatever means they use to do business.

> Use Case: Enable anonymous transactions such that the identity of the
> customer is not discoverable by merchants or payment processors.
> 

IMHO Anonymity doesn’t exist and/or is very expensive / difficult / often pointless and counterproductive.

Persona - if i goto shop, buy fish - i should, if required, be capable of saying - i’m the guy who bought that fish - hi - or, if i choose to give details to them - say - i’m happy to support your business.  In some cases, i might get a discount for loyalty, or if i want to save the whales - perhaps i’ll be happy for some organisation to scream from the virtual hilltops of WWW that i’d like their to be whales in 150+ years, and that i’m one of the many. 

Getting involved in the ‘anonymous’ debate, is pointless.  I’d talk in terms of displacement and persona.  i can engage an ‘agent’ to act as a ‘proxy’ to carry out a task on my behalf.  This should not remove my legal obligations in anyway that would otherwise be put upon me if i undertook that task myself; but rather, 

not everyone needs to know everything...

‘anonymity’ systems most often damages the rights of the vulnerable. ‘i created this work and provided it to a large company’, the large company can’t find the email and was working on it for years (apparently).  or mum’s thinking of getting divorced and is doing research on the computer - kids get home and theirs divorce advertising all over their web-session in the same machine account...

> Use Case: Jack wants to send Jill some money and asks Jill for a short,
> memorable payment identifier. Jill sends the payment identifier to Jack
> via an SMS message. Jack makes a payment using the short payment
> identifier; the payment processor translates the short payment
> identifier into a destination financial account for Jill.
> 
+1
> Use Case: A person pays a merchant using a short identifier. Prior to
> sending the payment, some information associated with the short
> identifier indicates to them that the short identifier is a verified
> short identifier for the merchant.
> 
+1
> Design Criteria: A person sets a second identity as a backup for
> accessing their first identity, should they lose the ability to use the
> first identity.
> 
We have one identity, as a ‘natural legal entity’.  we may create and participate with other identities, such as ‘incorporated legal entities’, yet we do so fundamentally (by law) as a unique identity.  Privacy, and related principles which are tangentially attributed with new forms of data - arguably benefit from the notional concept of ‘persona’, which in-turn can support both privacy requirements and realities surrounding ‘duty’ of roles in connection to acting on behalf of an identity; or, as a personal choice by a legal entity should they be provided the opportunity to make that choice and it is legal to do so.

I met a homeless person last friday - He told me of the background that led to his wanderings on the street.  He’d left his wife and 4 children in country victoria, a former furniture carpenter, unable to find a residence, he was on the streets of melbourne. he said that because he does not have a drug-problem, less assistance is available for him in terms of emergency housing; and that, on an occasion when he stayed in a shelter, someone stole his possessions including his identity documents; which means his less capable of obtaining government assistance - including that of obtaining new identity documents, and the servicing the fees incurred in obtaining those identity documents; let alone, finding a residence, a job, etc.

He sought to maintain a relationship with his children, who did not know he was homeless and therefore did not want to go to somewhere warmer (it’s winter in melbourne).  Having done a great deal of work in that ‘civic interest’ area, i know that the statistics surrounding the type of life experience that caused him to be on the street - well, it’s a rather extensive problem...

In consideration; i’ve selected to pursue this course as i believe that Identity is a right.  It should be accessible, and not manipulatively provided, thereby entitling systemically defined incursion, facilitated by external parties who in extreme ends of the use-case spectrum, can result in revoking civic rights of a person, to be acknowledged as a citizen of a state, entitled to legal protection, support as an entity before the law, without identity and identity related services - we are not all equal before the law.  Implicitly, within the realm of ‘www’ and ‘data services’ , identity data has an array of other traits connected to it, as embodied (by draft) in this RASPS Concept.  Incurring a mechanism to ensure identity is a valid and accessible right - is perhaps as important as ensuring a person has the right to control their own identity, in-turn the information collected and made available about them, to others, with others, etc.

I know this response has an array of tangents build-into what is a relatively brief, still early stage output; hopefully forming a compelling contribution, that may start something to better consider the identity structure requirements.  In relation to the ‘RASPS’ work, i think their is merit to consider whether or not this type of work could be supported through this web-payments initiative, perhaps with a subgroup / sub-working group - to better consider the various implications to how the identity systems may best work, and in-turn support the e-commerce related specifications in a better way overall…

As noted earlier; members of this group and other related W3 Community groups (direct or indirectly) have the technical capacities to consider how WWW solutions may technical service these identity related functions.  Yet the scope of work, isn’t simply about defining an ontology.

> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Marathonic Dawn of Web Payments
> http://manu.sporny.org/2014/dawn-of-web-payments/
> 
Received on Wednesday, 16 July 2014 06:28:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:38 UTC