Re: discovering an authority endpoint

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?

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