Re: Proposed VC Use Case: Consignment of Claims

On Fri, 4 Mar 2016 at 09:06 Dave Longley <dlongley@digitalbazaar.com> wrote:

> On 03/03/2016 01:05 PM, Steven Rowat wrote:
> > On 3/3/16 6:10 AM, Eric Korb wrote:
> >> A.6 Consignment of Claims
> >>
> >> A.6.1 Holder Consigns Their Claim to Another Trusted Entity
> >
> > +1. The language of this Consignment of Claims in A.6.1 was a delight to
> > read -- fully explained itself to me by the examples themselves, which
> > were easy to follow.
> >
> > IMO there are many important uses for this. Tim put in some others in
> > his reply.
>
> I agree the there are important uses for this. We may also need more
> than one way of doing it -- depending on the use case. For example,
> there are delegated-authorization use cases here that we've briefly
> discussed that could be modeled via Google macaroons:
>
> Nice. Link: http://research.google.com/pubs/pub41892.html


> 1. A service could control access via a macaroon that requires a
> particular credential/claim as a caveat.
>
> 2. Someone who is eligible to use the service could provide their
> credential/claim to an authenticating service to discharge that caveat.
>
> 3. That person can then apply their own caveat that requires a
> particular credential/claim that appropriately identifies another
> trusted party that they give the macaroon to. This party can then act on
> their behalf, provided that they can discharge the caveat by presenting
> the required credential/claim.
>
> Some other use cases, for example, where the main party is incapacitated
> or cannot be looped into the authentication process, wouldn't be as
> easily solved using this sort of method.
>
> I think supporting this concept is worth considering during the data
> model/syntax phase -- even if we can't get into the protocols required
> to fully support the use cases.
>

Assignment of access in our current service-centric architecture is IMHO
quite vast and often opaque to end-users.  Many of the most significant
data-breaches relate to the contexual use of delegated authority over
sensitive information; required for one particular purpose, yet stored
within an environment that fails to differentiate that purpose with any
other purpose the storage location is used for on a more generalised basis.


I also thing the concept of delegated authority circumvents the previous
topic of pseudo anonymity by providing a contractual method for license,
that may be contained within a document the subject never reads or is
subject to variation with or without the end-users input via a click of a
button, blocking access to their information / service until that button is
affirmatively clicked.

In seeking not to weaken the foundation of a credential document (that is
an HTTP signed Document with embedded Linked-data) my consideration is in
the use of syndicated document strategies and indeed ontologies which
in-turn may also be signed / verified.



> >
> > One that's not mentioned yet I think, and I think is important, is the
> > legal one for end of life or incapacity (like your example, but more
> > inclusive): Attorney for Health Care, Attorney for Financial Affairs --
> > named differently in different jurisdictions but meaning that person B
> > acts as the legal agent for Person A when person A is incapacitated, in
> > a whole realm of legal acts: decisions with doctors, decisions with
> > banks. These uses should definitely be covered in a seamless way by VCs
> > if possible, and Consignment seems a good way to do that.
> >
>
End of life is a particularly good use-case that has an enormous amount of
work done already, without good answers / solutions.

when people become deceased the first implication is cause of death and
obtaining information to allow the person to rest in peace, providing loved
ones (or indeed community if it were due to an act of terror for example)
the means to move forward with confidence of understandings.

Increasingly also social network and other data repositories which have
and/or display information about the person needs to be accessed and
addressed by someone.  This does not necessarily mean they shouldn't be
entitled to privacy?  that is a choice that needs to be made at various
levels.

This use-case in-turn also supports adaption or delegated authority in
life, whether it be for emergency services, court-orders or secretarial /
departmental authority delegation, seemingly the underlying elements relate
to the support for the notion of groups.


> > Though...it seems possible that some combination of other scenarios
> > already in the VC Use Cases contains this capability? Unfortunately some
> > of them are so dense as to be impenetrable for me, so I can't tell if
> > that's true or not. For instance,
> >
> > "A.3.8 Verifiable Claims as Qualifiers" -- maybe this is related? I
> > tried to understand it and gave up, admittedly quickly. The TL;DR
> > response took over and I fled. ;-)
>
> Perhaps the requirements from other use cases would allow someone to
> compose what they need in order to solve the consignment use cases, but
> it may be worth mentioning them anyway.
>
> Anyone else have thoughts on this?
>
> How about the concept of tracking a package from someone who put something
into a box, through the various agents, to either being say  - held up in
customs - or - delivered to the intended recipient?

Therein, if it got 'held up in customers' perhaps they uniquely have the
authority to inspect the package and thereby open it.  Whereas drivers or
other agents do not have that implied right. Therefore allowing the
recipient to look at the tracking data and identify, if the package was
opened, who opened it.

Another of the methodologies for considering this use-case i've found
relatively simple to digest, is the way in which a friend has his keys cut.
he has several homes, business locations, vehicles, a boat a plane, etc.
 he carries one key and issues others relating to the same system of locks
to others in his life.

Staffers at his business can't start his car or get into his house.
Syndicate members for the boat can't get into the business, etc.  yet his
wife and children have different 'permissions' cut into the keying system.
 obviously this is a physical key, not a digital one that includes the use
of graph database technology; yet, we're effectively talking about the same
type of ontology and perhaps outlining this type of 'check-box' styled
permissions set may result in better understanding how the mechanics of
ontology defined use of issued, signed credentials may in-turn support
delegated authority and indeed; what accessibility issues exist in relation
to understanding the contents and concepts embedded in a credential,
perhaps even via means of a look-up service much like creativecommons or
dbpedia, to provide reference around the definitions  embedded into these
instruments.

I'm also not sure how the potential issues should be tabled as to create
use-cases we want to avoid or address.  if a service station network asks
over their local wifi network for you to provide delegated authority for a
fuel discount - well, I think we have ethical issues to address around
ensuring no lay person unwittingly provide access to 'everything' on an
unintended basis or perhaps rather, because they were not aware of the
implications.   Whilst i believe these technical means provide enormous
opportunities for highly granular ACL support, whilst adding accountable
recording  (as opposed to far less manageable 'backdoors' that have no
accounting layers to it) i also think that is part of the ideological
design, rather than the only possible outcome in delivery of these
technologies.

At present most sites provide the means to 'reset' access via email.  So
arguably, if a person knows enough about the target and has access to their
email (usually password is saved on a device, etc.) then they're able to go
through and get access; perhaps also identify which sites the target is
using via the data in the email, etc.  Often also, sites 'remind' the
person of their password in clear-text, and the other current methodology
involves the use of password managers, where the password management
application seemingly stores all the credentials for site access, et.al.

Whilst an array of hardware keys and other capabilities exist, the idea of
advancing the use of core identifiers without causing further damage to
privacy related considerations may well be a problem we can contribute to
solving.  i think the use of machine and network identifiers is quite
different to human agents and their affiliations, which in-turn relate to
authorities for specified purposes to specified data-related objects.

Therein is another set of considerations that led me to consider the means
in which to simply address the framework in which users author their own
ontological apparatus for utility of the technology. In-order to achieve
that i think consideration about the utility of LDP is well worth
considering and moreover, I think this area needs alot of consideration
really. I think that's the reality.

I think we need to set affirmed targets for our definition of pseudo
anonymity which may be used to guide our design principles for other areas,
and that the concept of 'high stakes' and 'low-stakes' needs to be broken
down a little more in-order to reflect the various considerations embodied
within the polarised concept, as to address the pragmatics of it.

I also think what we're able to achieve in V1.0 should likely be part of a
broader intended scope of works, that can be addressed in a staged manner.

Tim.h.

>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com
>
>