Re: discovering an authority endpoint

On 19 November 2014 15:48, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 11/19/2014 05:10 AM, Melvin Carvalho wrote:
> > 1. How do I know where to POST this file to, given that I may know
> > the authority already?
>
> At the moment, discovery happens by hitting a well-known URL. It's the
> same basic process as outlined in the Secure Messaging spec:
>
>
> https://web-payments.org/specs/source/secure-messaging/#the-key-registration-process
>
> The key things to look out for are the "configuration service", and the
> use of .well-known URLs.
>
> So, I believe our current implementation does something like this:
>
> 1. Hit the domain of the payment processor that's going to do the
>    transaction, for example:
>
>    https://dev.payswarm.com/.well-known/payswarm
>

works for me ... should we call it /webpayments going forward, instead of
payswarm?


>
> 2. Find the 'paymentService' entry and do a POST of the transaction to
>    that service.
>
> We have been toying with changing that entirely and getting rid of the
> .well-known URL and instead serving a JSON-LD document outlining all of
> the domain services available at a particular URL. So that
> .well-known/payswarm document above would instead be delivered when you
> hit the root URL for the domain, so the process would be:
>
> 1. Hit the root domain of the payment processor, for example:
>    https://dev.payswarm.com/
>    and content negotiate for JSON-LD, TURTLE, NQuads, etc. That would
>    return the 'paymentService' URL.
>

also works, not mutually exclusive with the first method -- maybe use hydra
and/or void?


>
> The benefit of this approach is that you can embed the services in the
> HTML document as JSON-LD or RDFa, or you can content negotiate for it.
> You also don't have to have special .well-known URL registries and the
> solution can be re-used for any sort of REST API web services on the
> site (and extended dynamically instead of having to go through IETF or
> W3C).
>
> Thoughts?
>
> > 2. Can I use PUT as well as POST?
>
> I think we decided on POST because you're creating a new transaction in
> the system, whereas PUT would mainly be used for existing transactions
> (or in systems where you know what the final transaction URL is going to
> be.
>
> > 3. Is signature mandatory, e.g. if user is already authenticated,
> > perhaps it's not always needed?
>
> Signature isn't mandatory if the user is authenticated. Keep in mind
> that PaySwarm allows 3rd parties to submit transactions on your behalf,
> and in that case, there'd be two signatures necessary:
>
> 1. The signature on the transaction that was authorized by the sender
>    of the value.
> 2. The signature on the transaction request that lets the system know
>    who's submitting the transaction and whether they have the authority
>    to do so.
>
> This 3rd party submission scenario is useful for escrow,
> disconnected-operation, delayed payments use cases.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: High-Stakes Credentials and Web Login
> http://manu.sporny.org/2014/identity-credentials/
>
>