- From: Timothy Holborn <timothy.holborn@gmail.com>
- Date: Sun, 13 Mar 2016 11:36:01 +0000
- To: "Stone, Matt" <matt.stone@pearson.com>, Steven Rowat <steven_rowat@sunshine.net>
- Cc: "public-credentials@w3.org" <public-credentials@w3.org>
- Message-ID: <CAM1Sok1Sy_L=RRr5QgcnUe0h_UtnfW78LwoJhDO5a-q+gg4ukQ@mail.gmail.com>
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