Re: discovering an authority endpoint

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