W3C home > Mailing lists > Public > public-webpayments@w3.org > November 2014

Re: discovering an authority endpoint

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Fri, 21 Nov 2014 15:05:52 +0100
Message-ID: <CAKaEYhKO1qiGsFXjnNkMRH3MZkmGtZJny5t4BPz6hO2VoLsX6w@mail.gmail.com>
To: Adrian Hope-Bailie <adrian@hopebailie.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>, Web Payments <public-webpayments@w3.org>
On 21 November 2014 14:55, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:

> Sure, but if you sent me an email and all I had to identify you was
>>> melvincarvalho@gmail.com how would I derive the uri
>>> http://melvincarvalho.com/?
>> In my use case the client side app will already know the user URL and be
>> looking for other information such as the payment provider.
>>> Federated identity is easy if your identity is defined in a domain you
>>> control.
>> Yes
>>> Well, it's also easy if it's not but you then need to trust the domain
>>> owner which is something we are attempting to avoid AFAIK.
>> If using http to derefernce then you need to trust the origin.  If using
>> http as a namespace that's not always the case (although most often it is)
> By trust, I mean you don't mind the person who controls the domain (in
> your case Gmail.com) processing all requests for your information and
> therefor learning about you over time.
> i.e. My understanding of what Credentials is trying to do that has not
> been achieved by other systems is: allow a person to store their identity
> data in one place and use (a possibly different service) a service to
> directs clients/relying parties to that data but for that third-party to
> not have the ability to "track" your movements online via the RPs that it
> processes requests for.

Yes, yhis is the case when the HTTP URI is dereferenced, but not if it's
cached.  Perhaps that's not an important distinction.

>>> The normalisation steps for an identifier are quite clever in OpenID
>>> Connect Discovery I think, they are worth looking at even if just for
>>> inspiration:
>>> http://openid.net/specs/openid-connect-discovery-1_0.html#IdentifierNormalization
>> Doesnt work for my use case due to:
>> 5. If the resulting URI contains a fragment component, it MUST be
>> stripped off, together with the fragment delimiter character "#".
> My comments here are really targeted at a problem that I don't think has
> been elegantly solved yet and should be on the Credentials CG agenda (i.e.
> not just your use case).
> I am throwing out some ideas for comment and trying to provide examples
> for clarity.
> Problem description:
> If all I have to identify a person is their email address how do I
> discover the service endpoints that will allow me to pay them, get info
> about them etc (obviously with their authority when required).

This is a (long standing) problem yes.  Fortunately not one for my use case
as the user HTTP URI is already known.

> Importantly, I believe the following to be true and important
> considerations:
> 1. Lack of a standard for discovering services based on a user identifier
> has resulted in various people inventing their own and this contributes to
> the Nascar problem for identity.
> Now, as the relying party, you need to know what type of IdP the user is
> using as well as their identifier because the protocol for discovering the
> IdP will be different each time.
> 2. Users are very familiar and comfortable with the idea of identifying
> themselves by an email address (possibly different ones for different
> identities - work vs personal).
> Other identifiers can easily be put in the email form:
> Mobile number: +271234567890@msisdn.org
> Social security number: 12345678@ussocialserv.gov
> Twitter Handle: myhandle@users.twitter.com

I dont see this as the case.  On facebook for example people identify using
<firstname> <lastname>.  email is only very occasionally used for login,
and often then people prefer to click a button than type.  Then again,
maybe I use facebook too much :)

> 3. Persuading users to now identify themselves using some other thing
> (like a URI) is very difficult and probably why OpenId is not yet as
> popular as it could/should be.

I dont think OpenID even lets you do this anymore, though it was the core
feature of the original OpenID nee. Yadis

> In may respects I like the simplicity of the Ripple/Stellar Federation
> protocol.
> 1. Take an email address, make some requests to specific URLs in the
> domain of the address in a predetermined order.
> 2. If you find the data you are looking for great, if not then ask the
> user to provide more info (like an IdP type?)

Yes, I like this approach.

>>> Given an identifier (email, URI etc) you can derive a host (domain) and
>>> resource identifier.
>>> They then use WebFinger to query the host for details on that particular
>>> resource but I agree with Manu that perhaps WebFinger (which uses
>>> .well-known URLs) is a bit clunky, on the flip side it is an IETF standards
>>> track RFC (http://tools.ietf.org/html/rfc7033).
>> Yes, webfinger is useful, when available, when you start with an email
>> address and would like to follow our nose for more information.
>>> So if you wanted to use your email address to be your identifier but
>>> your IdP info is hosted somewhere else your OpenID Connect identifier could
>>> be acct:melvincarvalho%40gmail.com@openid4.me.
>>> Note that openid4.me doesn't have to be your IdP it just needs to be a
>>> domain at which you can control the response to the following request and
>>> return the address of your IdP endpoints:
>>> I have tweaked this example from the spec to show how it may work for
>>> Web Payments, excuse the sloppiness, schema addresses are probably wrong
>>> and the JSON is almost definitely wrong maybe Manu or Dave can fix it :)
>>> GET /.well-known/webfinger?resource=acct%3Amelvincarvalho%40gmail.com%
>>> 40openid4.me&rel=http%3A%2F%2Fweb-payments.org%2Fspecs%2F1.0%2Fpayee
>>> HTTP/1.1
>>> Host: openid4.me
>>> HTTP/1.1 200 OK
>>> Content-Type: application/ld+json
>>> {
>>>    "@context": "https://w3id.org/payswarm/v1",
>>>    "id": "acct:melvincarvalho%40gmail.com@openid4.me",
>>>    "type": "Payee",
>>>    "destination": "
>>> http://payswarm.example.com/people/melvincarvalho%40gmail.com#account-3
>>> ",
>>> }
>> Thanks.  I think webfinger requires you to use JRD which works well in
>> most cases, but there are some examples where it's not an ideal fit, such
>> as with unordered lists of URI or predicates that take more than one
>> literal, granted this is an edge case.
> WebFinger is on the IETF standards track, I see a debate about it vs
> another method ahead similar to the one about JOSE and SM lately.
> It could very easily be just the initial step in a broader linked data
> based discovery process.

Yes to both.  Webfinger is useful to find more information from an email
address, in some cases.  As part of an overall discovery library it's a
useful addition, but does not solve all problems.

> My example above is a bad one but what if the response was more like this
> instead:
> (I.e. It is JRD but the links are to JSON-LD resources.
>      HTTP/1.1 200 OK
>      Access-Control-Allow-Origin: *
>      Content-Type: application/jrd+json
>      {
>        "subject" : "acct:melvincarvalho%40gmail.com@openid4.me",
>        "aliases" :
>        [
>          "http://melvincarvalho.com/"
>        ],
>        "links" :
>        [
>          {
>            "rel" : "http://web-payments.org/specs/1.0/payee",
>            "href" : "http://melvincarvalho.com/payee" - A GET to this URL returns the object in my earlier example
>          },
>          {
>            "rel" : "http://webfinger.example/rel/businesscard",
>            "href" : "http://melvincarvalho.com/card.vcf"
>          }
>        ]
>      }
Received on Friday, 21 November 2014 14:06:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:37 UTC