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

On 5 June 2015 at 14:58, 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.
>
>
*INTERESTING EXAMPLE*
http://www.washingtonpost.com/blogs/style-blog/wp/2015/05/25/a-reminder-that-your-instagram-photos-arent-really-yours-someone-else-can-sell-them-for-90000/

Which in-turn interoperates with "choice of law"; therein, Copyright Law is
different in different regions

http://en.wikipedia.org/wiki/Copyright_law_of_Australia#Fair_dealing_and_other_exceptions


*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/
>>
>>
>