Re: discovering an authority endpoint

>
> 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.


>
>> 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).

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

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.

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?)


>> 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.

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"
         }
       ]
     }