Re: Thoughts on Communication and Framing (was: Re: Privacy enhancing/protecting credentials)

Timothy and Manu, thanks for writing these messages. I'm looking forward to
being able to enjoy some bite sized pieces.

Nate Otto, Developer
concentricsky.com

On Thu, Jun 4, 2015, 9:59 PM Timothy Holborn <timothy.holborn@gmail.com>
wrote:

> I think privacy credentials are a great use-case; being mindful that
> perhaps other terms not traditionally covered by privacy principles -
> likely apply to elements of the derivative use-cases for credentials.
>
> I recently reviewed the somewhat outdated 'identity credentials' spec:
> http://opencreds.org/specs/source/identity-credentials/ and felt that
> we've got a broader communications support problem, which is likely not
> helping our case.
>
> We're all time-poor; yet for the uninvolved to read a 'draft report' dated
> '26th may 2015' for 'identity credentials' that poorly conformed to the
> more recent outline: https://www.w3.org/community/credentials/
>
> Well, i'm sure it's confusing for some who may be interested, but want to
> understand what exactly we're doing...   This is an enormous job, and my
> comments should not be interpreted in anyway as a poor reflection upon
> those who are dedicated to its development to date.
>
> As noted previously; I've started drafting a framing paper in an attempt
> to structure the core-concepts that can be referenced and simplified to
> better understand how to author related formal documentation, or perhaps
> rather, how to get my head around how to best contribute to it:
> https://docs.google.com/document/d/1pRtTu9EssjhyyK3qkQymZepIUkqCwvMo6imnr4fqsrg/edit?usp=sharing
>
>
> Whilst some of these considerations may be deemed 'too broad', i still
> consider that the project seeks to provide an option in the marketplace,
> that will have some particular qualities not shared with market-based
> alternatives.
>
> It also sounds like the use-case documentation needs more work; and that
> this work, should support improved documentation for the use-cases that
> specifically support payments; and in relation to the broader field. So,
> in-turn I've been thinking about the methodology.
>
> is the design process effectively structured as to support the needs of
> the standards project and was the issues of use-cases not being documented
> possibly due to a process related issue.
>
> to test this hypothesis; i'm putting forward some ideas around a perceived
> modelling issue that rather than simply documenting in an iterative
> fashion, credentials use-cases; may inturn look more introspectively as the
> essence of the undertaking, form a method to express that effectively; and
> in-turn describe, using user-cases, etc.
>
> Inherently; perhaps the idea of completing an exhaustive list of use-cases
> would be a mission that we'd fail by design simply due to the flexibility
> of the design and how linked-data may be used to support enumerator
> use-cases; and that in an attempt to deal with this problem, we may be led
> to describing business applications of a standard; rather than useful
> documentation surrounding the standard itself, as part of our cooperative
> collaboration and work, towards the W3C Community (and related) work
> specifically.
>
> So, when thinking about it; i tried to find other precedents.
>
> *(Perhaps i'm misguided, but the thinking also considers that the W3C
> process is about defining the open-standards technology itself and that the
> role of W3C is particular, inter-operating with other 'standards' bodies
> where undertakings fall outside of W3C workflow, et.al <http://et.al>. )*
>
> *CONCEPT*
> So, how could HTML or Linked-Data be described from a 'top level' point of
> view?  Perhaps the iterative example would be to describe describe the
> use-cases of;
>
> - HTML to declare it is a method to author documents.
>
> - Linked-Data; a method to create documents that are machine and human
> readable.
>
> Implicit to Linked Data or RDF; are an array of qualities,
>
> For Example: Documents authored using Linked-Data enable the document to
> become an entry of any 'web-scale database (graphDB)' that has been
> authored to query the web for accessible documents; of which the authored
> linked-data document inter-operable through available permissions and
> shared linked-data definitions - regardless of where the document is stored
> on a WWW accessible machine/s.
>
> *(not suggesting these examples above are perfect, more illustrative about
> the form-factor of documentation process, surrounding communication
> strategies for project definitions, et.al <http://et.al>.) *
>
> *PROBLEMS*
> RE: Inter-operable dependencies between Credentials / WebPayments (if/when
> seeking the best possible outcome...)
>
> Does the the "best possible outcome" mandate (or mandate as an option...)
> Credentials for Payments in relation to the delivery of a solution for
> KYC/AML & Payments?
>
> These use-cases obviously set a particular level of security for the
> output; as to ensure the outcome is compliant with relevant fiduciary
> responsibilities, incumbent upon proposed users of the work; save failure
> of the apparatus.
>
> In other similarly areas: I wanted to acknowledge the Good Questions that
> were posed,
>
> - Can we use it for health, what are the use-cases.
> - We have demand in academia.
>
> Yet; in the developed documentation since Credentials workflow was split
> out of WebPayments; Why have we missed the Payments Use-cases?
>
> In-Turn more / new use-cases such as the use of credentials for privacy
> emerge.  Really very important; but perhaps, we're in-turn working on
> solving business problems that relate to the USE of proposed standards
> technologies; rather than communicating effectively what the proposed
> standards technology actually is; and what particular function is uniquely
> carries out.
>
> In some ways, it feels a bit like trying to describe the possible
> use-cases for HTML or a Web-Browser; I think the first web-browser
> supported read/write, a function later dropped - as memory serves.  Herein;
> if we go about it without an optimized pathway; we might end-up loosing a
> critical function and/or end-up with a result that is encumbered by
> unintended consequences.
>
> *SO THEREFORE: *what's the best, most extensible method to describe the
> project; and what it is attempting to achieve, How and Why...?
>
> *A MODERN, INITIAL DRAFT ATTEMPT: AT A SIMPLIFIED DESCRIPTION
>  (intended for Illustrative purposes only) **By: Timothy Holborn :)*
>
> W3 Credentials CG seek to deliver a means in which a secured container of
> information can be provided to a recipient; by providing a method in which
> a relation containing private and/or sensitive information may be digitally
> 'minted'[1] in a format that is compatible with HTTP for the purpose of
> providing digitally verifiable representation of a declared relation by an
> agent[2] (sameas:user-agent[3]?) to other agents in a manner that supports
> linked-data as a means to describe fiduciary[4] terms[5] minted into the
> credential used by the agents.  This proposed open, verifiable credential
> format supports both machine and human read/write interoperability, in a
> manner that that is designed to support issuance, consumption and use by
> any agent; with the minimum viable energy consumption profile; delivered as
> an open-standard in a manner that is fit-for-purpose for Banking and other
> sensitivity use-cases that incorporate sensitivity around a complex group
> of predicates that are cumulatively required in relation to the life-cycle
> from creation to disposal; Open 'Credentialing' technology format.
>
> *THE USE OF SOPHISTICATED USER-STORIES *
> IMHO; the remarkable benefit that may be achieved should we be successful
> with the credentials project; is not something that is simply defined in an
> isolated transactional use-case, but rather, exhibited in relation to the
> complex set of transaction related instances that represent an life-cycle
> embodiment of a particular event. In this way, it is similar to the
> challenge faced when first describing what HTML and WebBrowsers are useful
> for; as each of the particular functions probably had some way of being
> serviced with existing technology; but cumulatively, and particularly
> mindfully of a non-iterative but rather illustrative approach - highlighted
> the benefits of a common-format - why WWW - was a good idea, something
> worth spending time on investigating further (the rest is history...)...
>
> So to explore this concept; here are some iterative attempt to describe
> the perceived future complexity of use-cases; which therein, embody
> sufficient illustrative elements to improve communicative support for why
> the standards project is worthy of support (based upon my declared and/or
> implicit assumptions, et.al)
>
>
> *USE-CASE EXAMPLES: PHOTOS*
> Alice wants to share some of her private photos with bob.  Alice creates a
> document using linked-data that describes the permissions, copyright
> information, creative commons and commercial usage agreements for her
> photos which Alice then collects together and produces a credential that
> she sends bob so that he can access them.
>
> In this use-case; Alice may store her photos privately on her own
> web-hosting account.  Bob may have a webpage he build that connects to his
> own server; or, his web-browser might have functionality built-into it,
> that supports navigation; perhaps, commercial photo editing software can
> inter-operate with the credential and access the photos directly.
>
> *EXTENDED SUPPORT: Sub-Use Case - EG: Credentialing s**upport for Agent:
> Sharing, collaborating & implicit economic declarations.*
> The Permissions provided by Alice to Bob allowed him to make modifications
> to the photos, so long as they were sent back to Alice as derivatives. Bob
> reviews the photos and believes he can alter / edit the images to 'fix
> them'.  Bob edits the photos, and in his photo editing software; saves the
> photo.  When Bob saves the derivative of the photo, bob generates a new
> credential that looks for the information in the original credential; then
> appends additional information to describe that he has edited it noting the
> original resource; Alice receives a notification that accepts the new
> photos, and now Alice has both her original photos and some edited photos,
> that incorporate the information about the contributions of both Alice and
> Bob.
>
> *NOTES: *
> This example illustrates the concept that both Alice and Bob have one of
> more credential issuing services that they use to validate the way in which
> they're sharing, and collaborating.   These types of use-cases could be
> extended to include examples where the sales-price of the photos were set
> by Alice to a particular amount (or therein, have a floor-price, or relate
> to a pricing table that's accessible in RDF/linked-data, etc.).  Alice may
> in-turn have shared those photos with bob, simply because she wanted to
> share the photos with her friend; perhaps after that, bob 'fixed them up'
> because he wanted to; and if Alice was happy with them, perhaps she in-turn
> offers the new versions / derivatives and shares some of the sales price
> with bob (should someone purchase them).
>
> Alice could always work with other people to create derivatives; and if
> they used the original work, the use of the photos may not in-turn
> incorporate a revenue to bob but rather whoever the new contributor is;
> which in-turn may relate to variations in the terms of which the original
> assets were shared by Alice, as defined in the credential record.
>
> In a related embodiment;  Alice may want to make the photos available to
> anyone on the web to use subject to commercial terms, that she seeks where
> the photos are used for commercial purposes.  She's happy for them to be
> used for education purposes, or by people who love her photos but aren't
> making alot of cash out of them; yet even if someone takes it to get it
> printed for their wall at home, she things that much like the operator of
> the printing business - she should get some sort of recognition for her
> work if its valued by others; whether that simply be cases where she cares
> only about attribution (that that of others who have helped her); or
> sharing in the revenue created, that in-turn could be used so that Alice
> can purchase new camera equipment.
>
> Herein; the formulate approach of Credentials not-only allows the capacity
> to furnish 'fiduciary terms', but also the capacity to relate to other
> 'credentialing' related services such as a bank-account.  This in-turn may
> be used in an environment where an automated printing machine can accept
> payment to printing a related product; and that as part of the function of
> that machine, a fee, where it is applicable, may be provided digitally to
> Alice and any other contributors of that work in real-time, at point of
> sale.
>
> *Support for IoT and Corporate Use Embedded within Use-Case*
> In the Above use-case, the Printer may have a credential that enables them
> to associate the service of printing with the life-cycle information of the
> photo and its use.  Additionally, should the printer have some form of
> 'print vending machines' these machines may have credentials that relate to
> the operator of the machine; which in-turn may support automation of
> banking and copyright related transaction information and fulfillment of
> defined 'fiduciary terms' by supply chain related agents.
>
>
> *Buying a Motor Vehicle*
> Joe wants to purchase a new vehicle.  He finds a dealer who is offering a
> vehicle he likes and speaks to their sales agent Frank.  Joe asks the Frank
> to Take the Vehicle for a Test-Drive.
>
> Frank and Joe start to entertain the idea of Joe purchasing this vehicle.
> Frank would like to know whether Joe has the capacity to purchase the
> vehicle or whether, Joe's simply interested in going for a test-drive with
> no-capacity to make a transaction. Frank has a family and it's important he
> spends his time on sales opportunities. Frank does not have alot of time to
> waste on 'tyre kickers'.
>
> Joe uses his phone to scale the 2D Barcode on the car; then adds Frank as
> a contact. Joe has a look at the information about the car on his phone
> that his obtained by scanning the 2d barcode. He is concerned about the
> service history and the price in relation to other similar cars given his
> view of the car in the lot, and the information about it, that his reading
> on his phone.
>
> Frank suggests they share some more details and if the information
> provided stacks up, then joe should borrow the car and if he likes it,
> they'll negotiate on the price if he is still interested.
>
> Joe presses a button on his phone, and Frank gets a 'green light'
> indicator that shows that joe has a license and has the financial capacity
> to purchase the car.
>
> -- > Whilst it is non of franks business; Joe has a linked-credential that
> denotes the intention of his parents to purchase a vehicle for him to a
> particular value, which in-turn contributed towards getting the 'green
> light' he needed, before going to find a car he likes.
>
> Frank is happy to provide Joe access to the car, to take for a
> test-drive.  Frank and Joe issues credentials for the purpose of the
> test-drive, that support insuring the Joe in case he has an accident;
> whilst also supporting Frank, in case Joe doesn't come back with the car.
>
> Joe takes the car for a test-drive and notices that there are some
> mechanical issues with the car.  He enters the information in his record
> that relates to the vehicle, and the application on his phone provides an
> estimation of the cost to fix the problem in addition to any information
> about whether by law, Frank needs to fix that problem before he sells it to
> Joe.
>
> Joe Returns. Frank and Joe talk about the price, which results in Frank
> finishing the sales-opportunity by issuing Joe an Offer that is attached to
> the record stored in relation to his phone application.  Joe informs frank
> he'll be back, frank limits the offer to a few days hoping to close a deal
> before the time his commissions need to be finalized for the month; Joe
> goes to have a look at other vehicles.
>
> *EDUCATION*
> The Minister for ICT has a discussion at a BBQ with some friends who work
> in the education field; about why he does not have a qualification within
> fields of IT and Telecommunications, being that he is the minister.  The
> Minister retorts that the education minister has no academic proof he knows
> how to use the ICT either; which in-turn, may be interpreted as a
> limitation to his capacity to carry out his role.
>
> The minister asks staff to investigate how he might be able to obtain
> professional or academic recognition for the skills have led to the social
> endorsement of the minister, in becoming the minister, being deemed most
> suitable for carrying out the role on behalf of the people.
>
> NANODEGREES[6]: Nano-degrees are emerging in the marketplace as a means to
> provide 'qualification' for particular skills that may be constituents of
> broader formal qualifications. Whereas it may be argued that traditional
> formats of Tertiary Education were to some degree uniquely designed; which
> in-turn limited the capacity for applying 'recognition of prior learning'
> or RPL due to the specific design of the course; Nano-Degree enable the
> development of new formula that may better address transparency with regard
> to skills, professional development, the role of academia and academic
> qualification.
>
> EG: Social Media
> Staffers collate an array of materials they feel substantiate the skill
> set of the minister and provide that to an academic institution seeking '.
> The academic institution asks for additional information that supports some
> evidence that the minister knows how to use 'social-media'; staffers
> in-turn send a link to the minister asking that the minister click on the
> link, which in-turn queries the ministers social-network graph to identify
> whether the minister has carried out sufficient use of the technology to
> justify accreditation within the field.
>
> *CREDENTIAL FUNCTIONALITY: LINKED-DATA IMPLICATIONS*
> The above fictional outline; may be facilitated in an environment where
> industry scale disruption is occurring between traditional training and
> academic institutions; and emerging market-entrants. Linked-Data can not
> only be used to identify information relating to the assessment of an
> individuals skill-set; but also, inter-institutional assessment orientated
> delineation.
>
> through the use of 'sameAs[7]' references in notation; a particular skill
> that has been assessed by a non-traditional institution; may be related to
> that of a traditional institution, or a multitude of institutions
> definition of the skills inherent within the definition of the skill.
>
> If the skill is whether someone understands how to author a web-page using
> HTML/CSS; this skill can be assessed in enumerate ways; as such,
> institutions themselves may find value/merit, in using credentials to
> capture a definition at a point of time (which is in-turn protected should
> that definition change at a later date); and in-turn associate a 'sameAs'
> reference, in relation to the tuition process embodied by that unit, within
> their broader academic service of providing any particular form of
> qualification.
>
> Whilst it is impossible to enumerate potential variations and/or
> embodiment; Credentials CG proposes an open-standards based enabling
> technology that aims to supports the capacity for agents (in their various
> embodiment and explicit relations) to make relations, associations in a
> manner that can be verified.
>
> We envisage OpenCreds to provide an important and contributory innovation
> for the purpose of furnishing HTTP agents with the capacity to declare
> fiduciary terms and relations, for use by other agents; in an extensible
> and decentralised manner.
>
> This iterative design process has been undertaken in a manner that seeks
> to shield agents on a universal basis; from patent related encumbrances
> otherwise necessitating an agent to furnish and maintain relation to a
> particular agent with a license fee, that may be varied over time; as a
> prerequisite put upon agents seeking to be furnished with apparatus
> enabling the capacity to make declaration in a format that is machine and
> human readable; to flexibly, safely and securely communicate and purport
> particular ''fudicary terms' to other agents; as required by society in
> relation to the agent.
>
>
> DRAFT CONSIDERATIONS HEREIN
> This is a relatively quickly authored draft that attempts to deal with
> some of the underlying issues surrounding the status of development for
> credentials; and how the work is, from my individual perspective alone,
> being carried out, incumbent upon an array of premise relating to the
> undertaking itself.
>
> I hope this elements of this draft note are deemed useful.
>
> Cheers,
>
> Timothy Holborn.
>
> [1] http://en.wikipedia.org/wiki/United_States_Mint
> [2] http://xmlns.com/foaf/spec/#term_Agent
> [3] http://en.wikipedia.org/wiki/User_agent
> [4] http://en.wikipedia.org/wiki/Fiduciary
> [5] http://en.wikipedia.org/wiki/Term_(logic)
> [6] https://www.udacity.com/nanodegree
> [7] http://www.w3.org/TR/owl-ref/#sameAs-def
>
>
> On 4 June 2015 at 23:28, Manu Sporny <msporny@digitalbazaar.com> wrote:
>
>> One set of use cases that keep coming up are privacy enhancing
>> credentials. Specifically, can the ID that's associated with a
>> credential be used to track an individual between colluding sites (the
>> answer is clearly, yes). So, we've engaged the Cryptography Forum
>> Research Group[1] in an attempt to discover the most cutting edge ways
>> of establishing trustworthy credentials that are also privacy protecting:
>>
>> http://www.ietf.org/mail-archive/web/cfrg/current/msg06864.html
>>
>> We've also launched a research initiative at Digital Bazaar to look into
>> this space in more detail. We have a number of workable solutions that
>> we're looking at right now. They primarily revolve around creating a way
>> to automatically re-issue a short-lived bearer credential that is not
>> associated with an ID. Here's how the most promising solution we've come
>> up with could work:
>>
>> Definitions
>> -----------
>>
>> 'bearer credential' - a short-lived one-time use credential (5 minutes)
>> that is not associated with an identity that "proves" that the holder of
>> the credential has been verified by the issuer as having a valid
>> credential.
>>
>> Credential Flow
>> ---------------
>>
>> 1. An issuer issues a long-lived credential to a recipient. The
>>    credential has information in it on how to acquire a
>>    short-lived 'bearer credential'.
>> 2. When a consumer asks the recipient for a credential, the recipient's
>>    software notices that the credential could be provided in an
>>    'anonymous' fashion using a 'bearer credential'. The recipient is
>>    asked if they'd like to protect their privacy by using the
>>    'bearer credential'.
>> 3. The bearer credential is transmitted to the consumer, which verifies
>>    that the digital signature from the issuer is valid.
>>
>> The issuer always has the option to reject bearer credentials if
>> pseudo-anonymity isn't desired on their end.
>>
>> This mechanism could be built into a browser's "Incognito mode" such
>> that only bearer credentials can be used in "incognito mode".
>>
>> This is just a heads-up that we're looking into it and have a few
>> solutions that we think may be workable.
>>
>> -- manu
>>
>> [1] https://irtf.org/cfrg
>
>
>>
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: Web Payments: The Architect, the Sage, and the Moral Voice
>> https://manu.sporny.org/2015/payments-collaboration/
>>
>>