- From: Timothy Holborn <timothy.holborn@gmail.com>
- Date: Sat, 15 Mar 2014 22:53:22 +1100
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: "public-webpayments@w3.org" <public-webpayments@w3.org>
Reading the spec, https://web-payments.org/specs/source/web-identity/ It appears to me your outlining a validation process... Therein, A thought that came to mind is that it's about identity validation, out of which process results a RDF / linked data credential, associated to an identity. I really like the use of the term entity. I imagine there's entities (referring to legal entities? Or living things??) and things (manufactured by some sort of process, by humans perhaps; could include, accounts, concepts, machines, etc. A degree is a concept? Relationships are things / concepts, I guess therein; things have a reliable way of proving a certain concept..) Also; where the spec states "should" use tls; what's the harm in specifying it? The subject alternative name (x.509v3) seems like a no-brainer. Perhaps, in case of compatibility issues, etc. Have two separate levels. One level that uses certs, another that doesn't. Big thing I see about the certs, isn't so much about issuing them to a client (end user device). I imagine we want to put the user in control of how their identity is used... Also: have you considered the use of badges?? A number of different service standards have different levels of "know your customer" etc. Perhaps some services don't care who's making the transaction, as long as the financial amount doesn't bounce and the product / service is for filled. Other applications might need a higher level of identity assurance. Badges could be used by consumers to have a visual cue around what level of auth they need for a specified service. This could also be used to give users some sort of cue around data private / how vendors will use info provided. Thinking along the lines of the Creative Commons rdf licensing thing. But that's a different subject. Timh.
Received on Saturday, 15 March 2014 11:53:56 UTC