Re: discovering an authority endpoint

On 21 November 2014 09:37, 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)


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


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


>
>
> On 21 November 2014 05:41, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On 21 November 2014 02:42, Adrian Hope-Bailie <adrian@hopebailie.com>
>> wrote:
>>
>>> Have you considered also using DNS SRV records and/or DNS based service
>>> discovery (http://www.ietf.org/rfc/rfc6763.txt) as options?
>>> I tend to agree with Kingsley that many options is a good thing and the
>>> spec should dictate the order in which these will be probed so that it is
>>> clear which will be used if there are many and they possibly return
>>> different data.
>>>
>>> Consider also the use case of someone wishing to have their services
>>> listed somewhere but their identifier is at a domain they don't own, like
>>> gmail.com.
>>> If someone@gmail.com wants to receive a payment where does the payer
>>> start to discover the payment services for that payee?
>>>
>>
>> I can almost do this already.
>>
>> On my homepage my email address is mailto:melvincarvalho@gmail.com :
>>
>>
>> http://graphite.ecs.soton.ac.uk/browser/?uri=http%3A%2F%2Fmelvincarvalho.com%2F
>>
>> From this you can do a reverse link ("rev") to my identity and find out
>> my name, avatar, interests and friends.
>>
>> I havent yet added a payment provider, but once I understand the format I
>> can do it in a few seconds.  From there I can find the endpoint to make
>> transactions.
>>
>>
>>>
>>> Perhaps we should allow for some filter criteria in the discovery
>>> request?
>>>
>>>
>>>
>>>
>>> On 20 November 2014 16:36, Melvin Carvalho <melvincarvalho@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 20 November 2014 06:16, Manu Sporny <msporny@digitalbazaar.com>
>>>> wrote:
>>>>
>>>>> On 11/19/2014 01:50 PM, Melvin Carvalho wrote:
>>>>> > works for me ... should we call it /webpayments going forward,
>>>>> > instead of payswarm?
>>>>>
>>>>> I'm fine with that as long as there are no objections from the
>>>>> community. We didn't want to foist this payswarm approach on the
>>>>> community unless it agreed that it was a good path to follow.
>>>>>
>>>>
>>>> Ah, I see.  I'll be able to offer more comments after implementing it,
>>>> I think.
>>>>
>>>>
>>>>>
>>>>> > also works, not mutually exclusive with the first method -- maybe use
>>>>> > hydra and/or void?
>>>>>
>>>>> It's not mutually exclusive, but we do want to try and nail down the
>>>>> normative text. Which is the MUST here?
>>>>>
>>>>> 1. MUST expose service URLs at .well-known, or
>>>>> 2. MUST expose service URLs via either conneg or <script/> JSON-LD
>>>>>    tags in the root HTML document on the domain?
>>>>>
>>>>
>>>> I would also be happy to implement this.  Some comments.
>>>>
>>>> Isnt the root of the domain just another well known location?
>>>>
>>>> How is the relation from user to payment provider specified.  Just
>>>> thinking out loud, could it be the case that some payment providers would
>>>> not want to alter their home page, but rather, have a dedicated page for
>>>> discovery of endpoints?
>>>>
>>>> Personally, I'd like to see more RDF on domain root docs.
>>>>
>>>>
>>>>>
>>>>> Personally, I think we should reject the .well-known approach...
>>>>> because
>>>>> we're going to end up with a plethora of .well-known endpoint URLs and
>>>>> figuring out what REST API services a particular website exposes could
>>>>> end up requiring 20-40 HTTP requests vs. the 1 HTTP request to get the
>>>>> conneg'd root document containing all service endpoints.
>>>>>
>>>>> Thoughts? If you'd agree to it, and there are no objections from the
>>>>> rest of the community, we could just drop the .well-known approach.
>>>>>
>>>>
>>>> Would like to work through some examples and try to understand the pros
>>>> and cons before giving feedback.
>>>>
>>>> As a thought I like the .well-known pattern a lot because it's domain
>>>> independent and therefore quite decentralized.
>>>>
>>>>
>>>>>
>>>>> -- manu
>>>>>
>>>>> --
>>>>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>>>>> Founder/CEO - Digital Bazaar, Inc.
>>>>> blog: The Marathonic Dawn of Web Payments
>>>>> http://manu.sporny.org/2014/dawn-of-web-payments/
>>>>>
>>>>
>>>>
>>>
>>
>