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

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