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

Federated identity is easy if your identity is defined in a domain you
control.
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.

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

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

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


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