Re: discovering an authority endpoint

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