Re: Comments on draft charter [Was: Agenda: Verifiable Claims Teleconference - Tuesday, March 8th 2016]

What is the 'root' identifier and how can that be human?

There is a difference in design principles between design that intends to
support an online or digital root identifier denoting a person, versus a
set of design principles that result in the root identifier of a human
being the human and in-turn decentralising the security, privacy and other
mechanics relating to the identifiers about a human to be more effectively
human-centric rather than alternatives.

i also consider that security is an element of the requirements in that if
a 'root identifier' is designed to be online apparatus controlled by a
subset of incorporated agents or bots, then modification may decrease
available security to dependent entities.

herein is a differentiator between the concept of accountability and known
scope of any-such accountability chain, and how that relates to the
concept.of trust.

If the FBI says to a court it requires certain actions to be carried out,
we believe that dur to known technology this is the only means available to
pursue law enforcement.

yet this is within a centralised system rather than a decentralised system,
so in theory, apple controls the identifiers?

fragility seems to making progress. yet i'm not sure it encapsulates the
concepts herein.

I think its more about the design principles enabling a human centric
approach, as thr only organic life making claims will be humans and agents
/ actors embodying particular authority authorized by human actors
specifically.

Also appears to have consequence with regard to A.I. agents and any legal
responsibility relating those sorts of agents.

Yet, I do acknowledge complications.  I believe A.I. processes in
self-driving cars, for instance, have 'kill decisions' if accidents are
unavoidable.  Yet, generally with other products if they fail and cause
harm the MFG is responsible for the cost relating to the harm.  Perhaps
therein, credentials could be used to identify the particular decision of
the particular human entity/s who made the decisions, and upon what basis.
  Sometimes these decisions may result in outcomes that can be supported by
insurances in different ways i guess.  Depends on what the 'human agent'
wishes to disclose and to whom?

Seems to me the solution may offer something akin to an 'identity cloud',
as distinct from the current concept of 'super-providers'.

Humans purchase products which for the purpose of allowing communication of
that human with other humans, requires subscription with products called
'super providers' whereby the human becomes considered a constituent of the
'product' due to 'freely' being provided the 'service' of 'identity,
considered for purposes of advancement of society, sustainability of
organic life, safety, etc., et.al.

Block-Chain is a document related alternative, that is supported /
stabilised via computational hardware. The cost of manufacturing more
advanced computational hardware for this specified purpose is expensive and
therefore outside of the realm of accessibility for the majority of agents
other than via retail sale, when made available.

Credentials has the opportunity to be another alternative which may allow
humans to make claims both as agents for incorporated entities and as
natural legal entities. Credentials can also provide the means in which to
produce digital transcription of older non-computational methods, as is
exhibited throughout society beyond the recent history of computing
systems.

Credentials can provide accountability chains in addition to support of
credential packages which in-turn may augment particular claims into
internally referenced claim-documents that may be prepared for specified
use to and for specified parties.

There are probably use-cases for adding credential services to intelligence
related classified document distribution to specified parties by way of
these sorts of use-cases.  Whether or not that is transposed through to
watermarking related forensics or other means is kinda beyond the point.

IMHO, the ability to support symmetrical accountability systems is
important for both privacy and security/safety purposes.

no point in blaming the puppet.

Tim.H.






On Sun, 13 Mar 2016 6:05 PM Stone, Matt <matt.stone@pearson.com> wrote:

> Once we zero in in this "fragility" concept, I like it. Much better!
>
> On Saturday, March 12, 2016, Steven Rowat <steven_rowat@sunshine.net>
> wrote:
>
>> RE: "Identity fragility"
>>
>> I flagged this a few days ago and got no comments, but on re-reading the
>> Charter draft it still stands out for me, and this time I have a suggested
>> improvement.
>>
>> Currently, the Problem Statement includes:
>>
>> "In existing attribute exchange architectures (like SAML, OpenID Connect,
>> Login with SuperProviderX, etc.), users, and their verifiable claims, do
>> not independently exist from service providers. This means users can't
>> easily change their service provider without losing their digital identity.
>> This leads to vendor lock-in, identity fragility, reduced competition in
>> the marketplace, and reduced privacy for all stakeholders. "
>>
>> As this stands, the main direct problem for the credential holder --
>> besides privacy -- is 'identity fragility'. I'd suggest that:
>> a) that's vague
>> b) there are other things happening: IMO the vendor lock-in leads to
>> identity duplication, confusion, loss, and inaccuracy.
>>
>> Perhaps all those things together could be characterised as 'fragility',
>> but since the vendor lock-in issue is a major reason why verifiable claims
>> are needed, IMO it's best to spell it out. I suggest the last sentence be
>> amended to:
>>
>> "This leads to: vendor lock-in, identity fragility (duplication,
>> confusion, loss, and inaccuracy), reduced competition in the marketplace,
>> and reduced privacy for all stakeholders."
>>
>> And of course we could also fight about (I mean discuss) which of those
>> four descriptors are accurate, and/or add others.
>>
>> Steven
>>
>>
>>
>
> --
>
> =====
> Matt Stone
> 501-291-1599
>
>
>

Received on Sunday, 13 March 2016 11:36:41 UTC