Re: Web Identity 1.0 -- Draft Spec

Melvin,

The spec has changed considerably based on an attempt to answer the
questions you asked in this thread. See if the new text sheds any more
light on some of the design decisions:

https://web-payments.org/specs/source/web-identity/

On 01/01/2014 04:30 PM, Melvin Carvalho wrote:
> In terms of reading and writing there appear to be 4 verbs
> 
> read delete replace append
> 
> All via HTTP POST
> 
> First question that springs to mind is did you consider using
> 
> 1) HTTP Verbs such as PUT DELETE PATCH GET

Yes we did consider the standard HTTP verbs. Those verbs will be used
for the HTTP Signatures-based read/write mechanism. I've updated the
spec to outline how they will be used here:

https://web-payments.org/specs/source/web-identity/#accessing-the-identity

There are two mechanisms that allow a 3rd party to read protected
information from an identity. The first is an HTTP Signature-based
mechanism that allows any authorized client to access data that has been
pre-approved by the entity that controls access to the identity
information. The second is to use a browser-based mechanism that POSTs a
request to an identity, allowing the identity owner to interactively
decide what data access to allow or disallow.

You really need both mechanisms, AFAICT.

Reading information from an identity can be done via a regular GET
operation, but that's only going to give you the public information (if
no authentication information is provided). If authentication
information is provided, it will give you all data that you have access
to based on the authentication credentials you use.

To read the private information w/o prior authorization (an ACL is not
associated with you, which will most likely be the standard case), the
requestor is going to have to mediate the request through the entity
that controls the identity (the person that owns it, for instance). This
mediation is most likely going to flow through the browser, and if we do
that, we're going to need to specify what information the requestor
wants to read and then ask the owner if it's ok if the requestor reads
that information. For example, this could be the request that's sent:

POST /melvin?action=read&callback=http://requestor.com/cb
Host: identity.mybank.com

{
  "@context": "https://w3id.org/identity/v1",
  "mobileNumber": ""
}

You can't specify that information in a GET request very eloquently
(yes, you can shove it into the URL, but that's not a good solution if
you want to specify that you want lots of data). Furthermore, it's not
really a GET, it's a query. So, for the simple case of asking to read a
specific piece of information, it maps more naturally to POST than it
does to GET. Also keep in mind that the person may have more than one
mobileNumber, but may also only want to expose a particular one to the
requestor.

The dialog at their identity provider would ask them 1) if they want to
expose this information to the requestor, and 2) how much of the
information they want to expose.

So, I think you need both. Thoughts?

> 2) SPARQL update or JSON PATCH for this kind of operation

We did look at SPARQL, but requiring it was deemed to be overkill.
Hardly any Web Developers know what SPARQL is and asking them to use
that stack just so they can read/write identity information places a
very high barrier to entry. We're trying to do all of this with just
JSON-based tools and what you'd already get in a web browser.

While you can argue that HTTP Signatures are very much above this bar,
remember that the standard read/write functionality will be accessible
to anyone with a web stack that supports HTTP POST and JSON.

> 3) The Changeset vocab [1]
> 
> [1] http://docs.api.talis.com/getting-started/changesets

Overkill and no real standard for it. I think it would be more wise to
try to use a minimal set of JSON Patch until it becomes clear that we
need something more.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Worlds First Web Payments Workshop
http://www.w3.org/2013/10/payments/

Received on Friday, 3 January 2014 20:00:52 UTC