Discovery of OpenTransact assets
12 views
Skip to first unread message
Pelle Braendgaard
May 17, 2010, 11:04:22 PM5/17/10
to agile-banking
At BarCampBankSF3 Guillaume proposed the need for a simple discovery
protocol of openid assets. I mentioned the LLRD/XRD family of
discovery protocols, which Guillaume correctly thinks is too complex
for this purpose.
So I propose that we use a well known uri for discovery following the
"well-known uri" RFC below:
http://www.rfc-editor.org/rfc/rfc5785.txt
What this standard simply says is that you should be able to lookup
various things for discovery purposes at an agreed URI on each server.
These should be under the "/.well-known" path. So for our purposes the
well known URI might as well be "/.well-known/opentransact".
Just for proof of concept I implemented this for http://picomoney.com
http://picomoney.com/.well-known/opentransact
At the moment I just return a list of my standard json for each
currency on the server. This is obviously too application specific.
But I think the fields should be (with * indicating required):
- opentransact url*
- name*
- issuer_url (the url of whoever is the issuer of the asset. If not
specified it is assumed the root url)
- created_date
- circulation (useful but should never be required)
- symbol (a symbol to be used to prepend amounts for an asset)
- description
My current implementation just returns an array of assets. We may want
to wrap it into something like this allowing extra meta data:
{
"assets": [...],
"name":"PicoMoney",
"total_results": 143,
"items_per_page": 100,
"start_index": 0
}
We could also add OAuth discovery to it as the current work on this
seems to have stalled.
{
"assets": [...],
"name":"PicoMoney",
"total_results": 143,
"items_per_page": 100,
"start_index": 0,
"register_application":"http://picomoney.com/app/new",
"oauth10a_request_token_url":"http://picomoney.com/oauth/request_token",
"oauth10a_authorize_url":"http://picomoney.com/oauth/authorize",
"oauth10a_access_token_url":"http://picomoney.com/oauth/access_token",
"oauth11_token_url":"http://picomoney.com/oauth/token"
}
I am completely open to ideas here.
P
--
http://agree2.com - Reach Agreement!
http://stakeventures.com - My blog about startups and agile banking
--
You received this message because you are subscribed to the Google Groups "agile-banking" group.
To post to this group, send email to agile-...@googlegroups.com.
To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
protocol of openid assets. I mentioned the LLRD/XRD family of
discovery protocols, which Guillaume correctly thinks is too complex
for this purpose.
So I propose that we use a well known uri for discovery following the
"well-known uri" RFC below:
http://www.rfc-editor.org/rfc/rfc5785.txt
What this standard simply says is that you should be able to lookup
various things for discovery purposes at an agreed URI on each server.
These should be under the "/.well-known" path. So for our purposes the
well known URI might as well be "/.well-known/opentransact".
Just for proof of concept I implemented this for http://picomoney.com
http://picomoney.com/.well-known/opentransact
At the moment I just return a list of my standard json for each
currency on the server. This is obviously too application specific.
But I think the fields should be (with * indicating required):
- opentransact url*
- name*
- issuer_url (the url of whoever is the issuer of the asset. If not
specified it is assumed the root url)
- created_date
- circulation (useful but should never be required)
- symbol (a symbol to be used to prepend amounts for an asset)
- description
My current implementation just returns an array of assets. We may want
to wrap it into something like this allowing extra meta data:
{
"assets": [...],
"name":"PicoMoney",
"total_results": 143,
"items_per_page": 100,
"start_index": 0
}
We could also add OAuth discovery to it as the current work on this
seems to have stalled.
{
"assets": [...],
"name":"PicoMoney",
"total_results": 143,
"items_per_page": 100,
"start_index": 0,
"register_application":"http://picomoney.com/app/new",
"oauth10a_request_token_url":"http://picomoney.com/oauth/request_token",
"oauth10a_authorize_url":"http://picomoney.com/oauth/authorize",
"oauth10a_access_token_url":"http://picomoney.com/oauth/access_token",
"oauth11_token_url":"http://picomoney.com/oauth/token"
}
I am completely open to ideas here.
P
--
http://agree2.com - Reach Agreement!
http://stakeventures.com - My blog about startups and agile banking
--
You received this message because you are subscribed to the Google Groups "agile-banking" group.
To post to this group, send email to agile-...@googlegroups.com.
To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
Tom Brown
May 17, 2010, 11:18:20 PM5/17/10
to agile-...@googlegroups.com
you mean opentransact assets, not openid assets right?
-tom
Pelle Braendgaard
May 18, 2010, 12:11:23 AM5/18/10
to agile-...@googlegroups.com, agile-...@googlegroups.com
Duh. Yes opentransact. Been reading too much OpenID connect stuff today.
Sent from my iPhone
Sent from my iPhone
Guillaume P. Lebleu
May 19, 2010, 1:37:49 AM5/19/10
to agile-...@googlegroups.com
Hi Pelle and thank you for following up on this.
My use case for this is a customer presenting an identifier to a merchant, allowing the merchant's agent to quickly figure which currencie(s) they both use, and the corresponding OpenTransact URL(s) to process the authorization. With regards to this scenario, your proposal seems issuer/host-centric, not user-centric: as a user, I will likely have various accounts at various issuers on multiple hosts.
That said, it is relevant for discovery in the context of Ripple-like discovery of currencies available at a host, and I think it raises some interesting questions.
For instance, If I'm a bank named "Banked of Trust" holding Fed reserves and issuing checking account money, is the name "Bank of Trust's US dollars" or "US dollars". Is the issuer http://federalreserve.gov or http://bankoftrust.com ? I assume it's "Bank of Trust's US dollars" and http://bankoftrust.com, in which case, a unit may be useful, esp. in a Ripple context where you deal with different issuers issuing promises in the same unit.
Guillaume
My use case for this is a customer presenting an identifier to a merchant, allowing the merchant's agent to quickly figure which currencie(s) they both use, and the corresponding OpenTransact URL(s) to process the authorization. With regards to this scenario, your proposal seems issuer/host-centric, not user-centric: as a user, I will likely have various accounts at various issuers on multiple hosts.
That said, it is relevant for discovery in the context of Ripple-like discovery of currencies available at a host, and I think it raises some interesting questions.
For instance, If I'm a bank named "Banked of Trust" holding Fed reserves and issuing checking account money, is the name "Bank of Trust's US dollars" or "US dollars". Is the issuer http://federalreserve.gov or http://bankoftrust.com ? I assume it's "Bank of Trust's US dollars" and http://bankoftrust.com, in which case, a unit may be useful, esp. in a Ripple context where you deal with different issuers issuing promises in the same unit.
Guillaume
Jae Kwon
May 19, 2010, 3:33:01 AM5/19/10
to agile-...@googlegroups.com
Here are my thoughts on it. I don't know how it would be implemented with OpenTransact.
:: single currency, multiple banks ::
The Federal Reserve could have a digital certificate (that is also a certificate authority) that signs Bank of Trust's certificate, so anybody can know that the Bank of Trust is authorized to transact Fed Dollars directly. This way you can have separation between currency issuers and accounts.
:: multiple currencies, multiple banks ::
Otherwise, Bank of Trust's currency could be backed by accounts that are controlled by another bank certified by the Fed (meaning that this other bank's cert is signed by the Fed). To transact your BankOfTrust dollars with a merchant that only accepts Fed dollars, the user needs to obtain a document from the BankOfTrust that is redeemable for Fed dollars, and pass that along to the merchant.
- Jae
:: single currency, multiple banks ::
The Federal Reserve could have a digital certificate (that is also a certificate authority) that signs Bank of Trust's certificate, so anybody can know that the Bank of Trust is authorized to transact Fed Dollars directly. This way you can have separation between currency issuers and accounts.
:: multiple currencies, multiple banks ::
Otherwise, Bank of Trust's currency could be backed by accounts that are controlled by another bank certified by the Fed (meaning that this other bank's cert is signed by the Fed). To transact your BankOfTrust dollars with a merchant that only accepts Fed dollars, the user needs to obtain a document from the BankOfTrust that is redeemable for Fed dollars, and pass that along to the merchant.
- Jae
Jae Kwon
May 19, 2010, 3:54:09 AM5/19/10
to agile-...@googlegroups.com
I guess I'm sidestepping the problem by letting banks hold/transact multiple currencies in user accounts.
That way users don't need many accounts, and the ability/responsibility to resolve choice of currencies can be delegated to the user's bank.
On May 18, 2010, at 10:37 PM, Guillaume P. Lebleu wrote:
That way users don't need many accounts, and the ability/responsibility to resolve choice of currencies can be delegated to the user's bank.
On May 18, 2010, at 10:37 PM, Guillaume P. Lebleu wrote:
Pelle Braendgaard
May 19, 2010, 10:16:31 AM5/19/10
to agile-...@googlegroups.com
Good point on the user centric discovery. For that I believe the
http://xauth.org like approach is probably the best. As I mentioned
before we could implement this on opentransact.org.
How this works is that the user keeps his used currencies in his local
storage under the opentransact.org domain.
Providers and ecommerce sites write and read to this via a simple
javascript API. I'll double check the license of the xauth javascript
to see if we can build ontop of this.
We still need a server centric discovery method as well for various
other use cases.
P
http://xauth.org like approach is probably the best. As I mentioned
before we could implement this on opentransact.org.
How this works is that the user keeps his used currencies in his local
storage under the opentransact.org domain.
Providers and ecommerce sites write and read to this via a simple
javascript API. I'll double check the license of the xauth javascript
to see if we can build ontop of this.
We still need a server centric discovery method as well for various
other use cases.
P
HeresTomWithTheWeather
Jun 12, 2010, 4:00:37 AM6/12/10
to agile-banking
it seems another option for user centric discovery might be the rel-
payment microformat for a hyperlink:
http://microformats.org/wiki/rel-payment
"RelPayment is a microformat for making exchanges of support (be it
financial or otherwise) possible. By adding rel="payment" to a
hyperlink a page indicates that the destination of that hyperlink
provides a way to show or give support for the current page. For
example to give financial support to the owner of the current page."
so, you could navigate to an openid page like a google profile (which
already allows its owner to add to a list of hyperlinks) and your
browser plugin could detect those opentransact links and display them
to you and you can choose which one to make payment to.
cheers,
tom
On May 19, 9:16 am, Pelle Braendgaard <pe...@stakeventures.com> wrote:
> Good point on the user centric discovery. For that I believe thehttp://xauth.orglike approach is probably the best. As I mentioned
> >>http://stakeventures.com- My blog about startups and agile banking
payment microformat for a hyperlink:
http://microformats.org/wiki/rel-payment
"RelPayment is a microformat for making exchanges of support (be it
financial or otherwise) possible. By adding rel="payment" to a
hyperlink a page indicates that the destination of that hyperlink
provides a way to show or give support for the current page. For
example to give financial support to the owner of the current page."
so, you could navigate to an openid page like a google profile (which
already allows its owner to add to a list of hyperlinks) and your
browser plugin could detect those opentransact links and display them
to you and you can choose which one to make payment to.
cheers,
tom
On May 19, 9:16 am, Pelle Braendgaard <pe...@stakeventures.com> wrote:
> Good point on the user centric discovery. For that I believe thehttp://xauth.orglike approach is probably the best. As I mentioned
> before we could implement this on opentransact.org.
>
> How this works is that the user keeps his used currencies in his local
> storage under the opentransact.org domain.
>
> Providers and ecommerce sites write and read to this via a simple
> javascript API. I'll double check the license of the xauth javascript
> to see if we can build ontop of this.
>
> We still need a server centric discovery method as well for various
> other use cases.
>
> P
>
> On Wed, May 19, 2010 at 1:37 AM, Guillaume P. Lebleu
>
>
>
>
>
> <guilla...@lebleu.org> wrote:
> > Hi Pelle and thank you for following up on this.
>
> > My use case for this is a customer presenting an identifier to a merchant, allowing the merchant's agent to quickly figure which currencie(s) they both use, and the corresponding OpenTransact URL(s) to process the authorization. With regards to this scenario, your proposal seems issuer/host-centric, not user-centric: as a user, I will likely have various accounts at various issuers on multiple hosts.
>
> > That said, it is relevant for discovery in the context of Ripple-like discovery of currencies available at a host, and I think it raises some interesting questions.
>
> > For instance, If I'm a bank named "Banked of Trust" holding Fed reserves and issuing checking account money, is the name "Bank of Trust's US dollars" or "US dollars". Is the issuerhttp://federalreserve.govorhttp://bankoftrust.com? I assume it's "Bank of Trust's US dollars" andhttp://bankoftrust.com, in which case, a unit may be useful, esp. in a Ripple context where you deal with different issuers issuing promises in the same unit.
>
> How this works is that the user keeps his used currencies in his local
> storage under the opentransact.org domain.
>
> Providers and ecommerce sites write and read to this via a simple
> javascript API. I'll double check the license of the xauth javascript
> to see if we can build ontop of this.
>
> We still need a server centric discovery method as well for various
> other use cases.
>
> P
>
> On Wed, May 19, 2010 at 1:37 AM, Guillaume P. Lebleu
>
>
>
>
>
> <guilla...@lebleu.org> wrote:
> > Hi Pelle and thank you for following up on this.
>
> > My use case for this is a customer presenting an identifier to a merchant, allowing the merchant's agent to quickly figure which currencie(s) they both use, and the corresponding OpenTransact URL(s) to process the authorization. With regards to this scenario, your proposal seems issuer/host-centric, not user-centric: as a user, I will likely have various accounts at various issuers on multiple hosts.
>
> > That said, it is relevant for discovery in the context of Ripple-like discovery of currencies available at a host, and I think it raises some interesting questions.
>
>
> > Guillaume
>
> > On May 17, 2010, at 8:04 PM, Pelle Braendgaard wrote:
>
> >> At BarCampBankSF3 Guillaume proposed the need for a simple discovery
> >> protocol of openid assets. I mentioned the LLRD/XRD family of
> >> discovery protocols, which Guillaume correctly thinks is too complex
> >> for this purpose.
>
> >> So I propose that we use a well known uri for discovery following the
> >> "well-known uri" RFC below:
>
> >>http://www.rfc-editor.org/rfc/rfc5785.txt
>
> >> What this standard simply says is that you should be able to lookup
> >> various things for discovery purposes at an agreed URI on each server.
> >> These should be under the "/.well-known" path. So for our purposes the
> >> well known URI might as well be "/.well-known/opentransact".
>
> >> Just for proof of concept I implemented this forhttp://picomoney.com
> > Guillaume
>
> > On May 17, 2010, at 8:04 PM, Pelle Braendgaard wrote:
>
> >> At BarCampBankSF3 Guillaume proposed the need for a simple discovery
> >> protocol of openid assets. I mentioned the LLRD/XRD family of
> >> discovery protocols, which Guillaume correctly thinks is too complex
> >> for this purpose.
>
> >> So I propose that we use a well known uri for discovery following the
> >> "well-known uri" RFC below:
>
> >>http://www.rfc-editor.org/rfc/rfc5785.txt
>
> >> What this standard simply says is that you should be able to lookup
> >> various things for discovery purposes at an agreed URI on each server.
> >> These should be under the "/.well-known" path. So for our purposes the
> >> well known URI might as well be "/.well-known/opentransact".
>
>
> >> --
> >> You received this message because you are subscribed to the Google Groups "agile-banking" group.
> >> To post to this group, send email to agile-...@googlegroups.com.
> >> To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
> >> For more options, visit this group athttp://groups.google.com/group/agile-banking?hl=en.
> >> --
> >> You received this message because you are subscribed to the Google Groups "agile-banking" group.
> >> To post to this group, send email to agile-...@googlegroups.com.
> >> To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
>
> > --
> > You received this message because you are subscribed to the Google Groups "agile-banking" group.
> > To post to this group, send email to agile-...@googlegroups.com.
> > To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/agile-banking?hl=en.
>
> --http://agree2.com- Reach Agreement!http://stakeventures.com- My blog about startups and agile banking
> > --
> > You received this message because you are subscribed to the Google Groups "agile-banking" group.
> > To post to this group, send email to agile-...@googlegroups.com.
> > To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/agile-banking?hl=en.
>
HeresTomWithTheWeather
Jun 13, 2010, 2:57:49 AM6/13/10
to agile-banking
i did a screencast to demonstrate rel-payment:
http://www.opensourcecurrency.org/2010/06/opentransact-rel-payment-and-openid.html
cheers,
tom
On Jun 12, 3:00 am, HeresTomWithTheWeather
> > >>http://agree2.com-Reach Agreement!
> > >>http://stakeventures.com-My blog about startups and agile banking
http://www.opensourcecurrency.org/2010/06/opentransact-rel-payment-and-openid.html
cheers,
tom
On Jun 12, 3:00 am, HeresTomWithTheWeather
<herestomwiththeweat...@gmail.com> wrote:
> it seems another option for user centric discovery might be the rel-
> payment microformat for a hyperlink:
>
> http://microformats.org/wiki/rel-payment
>
> "RelPayment is a microformat for making exchanges of support (be it
> financial or otherwise) possible. By adding rel="payment" to a
> hyperlink a page indicates that the destination of that hyperlink
> provides a way to show or give support for the current page. For
> example to give financial support to the owner of the current page."
>
> so, you could navigate to an openid page like a google profile (which
> already allows its owner to add to a list of hyperlinks) and your
> browser plugin could detect those opentransact links and display them
> to you and you can choose which one to make payment to.
>
> cheers,
> tom
>
> On May 19, 9:16 am, Pelle Braendgaard <pe...@stakeventures.com> wrote:
>
>
>
> > Good point on the user centric discovery. For that I believe thehttp://xauth.orglikeapproach is probably the best. As I mentioned
> it seems another option for user centric discovery might be the rel-
> payment microformat for a hyperlink:
>
> http://microformats.org/wiki/rel-payment
>
> "RelPayment is a microformat for making exchanges of support (be it
> financial or otherwise) possible. By adding rel="payment" to a
> hyperlink a page indicates that the destination of that hyperlink
> provides a way to show or give support for the current page. For
> example to give financial support to the owner of the current page."
>
> so, you could navigate to an openid page like a google profile (which
> already allows its owner to add to a list of hyperlinks) and your
> browser plugin could detect those opentransact links and display them
> to you and you can choose which one to make payment to.
>
> cheers,
> tom
>
> On May 19, 9:16 am, Pelle Braendgaard <pe...@stakeventures.com> wrote:
>
>
>
> > before we could implement this on opentransact.org.
>
> > How this works is that the user keeps his used currencies in his local
> > storage under the opentransact.org domain.
>
> > Providers and ecommerce sites write and read to this via a simple
> > javascript API. I'll double check the license of the xauth javascript
> > to see if we can build ontop of this.
>
> > We still need a server centric discovery method as well for various
> > other use cases.
>
> > P
>
> > On Wed, May 19, 2010 at 1:37 AM, Guillaume P. Lebleu
>
> > <guilla...@lebleu.org> wrote:
> > > Hi Pelle and thank you for following up on this.
>
> > > My use case for this is a customer presenting an identifier to a merchant, allowing the merchant's agent to quickly figure which currencie(s) they both use, and the corresponding OpenTransact URL(s) to process the authorization. With regards to this scenario, your proposal seems issuer/host-centric, not user-centric: as a user, I will likely have various accounts at various issuers on multiple hosts.
>
> > > That said, it is relevant for discovery in the context of Ripple-like discovery of currencies available at a host, and I think it raises some interesting questions.
>
> > > For instance, If I'm a bank named "Banked of Trust" holding Fed reserves and issuing checking account money, is the name "Bank of Trust's US dollars" or "US dollars". Is the issuerhttp://federalreserve.govorhttp://bankoftrust.com?I assume it's "Bank of Trust's US dollars" andhttp://bankoftrust.com, in which case, a unit may be useful, esp. in a Ripple context where you deal with different issuers issuing promises in the same unit.
>
> > How this works is that the user keeps his used currencies in his local
> > storage under the opentransact.org domain.
>
> > Providers and ecommerce sites write and read to this via a simple
> > javascript API. I'll double check the license of the xauth javascript
> > to see if we can build ontop of this.
>
> > We still need a server centric discovery method as well for various
> > other use cases.
>
> > P
>
> > On Wed, May 19, 2010 at 1:37 AM, Guillaume P. Lebleu
>
> > <guilla...@lebleu.org> wrote:
> > > Hi Pelle and thank you for following up on this.
>
> > > My use case for this is a customer presenting an identifier to a merchant, allowing the merchant's agent to quickly figure which currencie(s) they both use, and the corresponding OpenTransact URL(s) to process the authorization. With regards to this scenario, your proposal seems issuer/host-centric, not user-centric: as a user, I will likely have various accounts at various issuers on multiple hosts.
>
> > > That said, it is relevant for discovery in the context of Ripple-like discovery of currencies available at a host, and I think it raises some interesting questions.
>
> > >>http://stakeventures.com-My blog about startups and agile banking
>
> > >> --
> > >> You received this message because you are subscribed to the Google Groups "agile-banking" group.
> > >> To post to this group, send email to agile-...@googlegroups.com.
> > >> To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
> > >> For more options, visit this group athttp://groups.google.com/group/agile-banking?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups "agile-banking" group.
> > > To post to this group, send email to agile-...@googlegroups.com.
> > > To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/agile-banking?hl=en.
>
> > --http://agree2.com-Reach Agreement!http://stakeventures.com-My blog about startups and agile banking
> > >> --
> > >> You received this message because you are subscribed to the Google Groups "agile-banking" group.
> > >> To post to this group, send email to agile-...@googlegroups.com.
> > >> To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
> > >> For more options, visit this group athttp://groups.google.com/group/agile-banking?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups "agile-banking" group.
> > > To post to this group, send email to agile-...@googlegroups.com.
> > > To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/agile-banking?hl=en.
>
HeresTomWithTheWeather
Jun 14, 2010, 7:57:48 PM6/14/10
to agile-banking
i'm interpreting the absence of replies to mean that either you think
that this is a bad idea, you haven't checked out the screencast or you
are trapped under something large. you might think it's a bad idea
because you may be viewing a particular blog post and then the
bookmarklet payment would fail because the url would not match the
openid. maybe the blogging service could put the openid in the html
header for the bookmarklet to read?
cheers,
tom
On Jun 13, 1:57 am, HeresTomWithTheWeather
> http://www.opensourcecurrency.org/2010/06/opentransact-rel-payment-an...
> > > >>http://stakeventures.com-Myblog about startups and agile banking
that this is a bad idea, you haven't checked out the screencast or you
are trapped under something large. you might think it's a bad idea
because you may be viewing a particular blog post and then the
bookmarklet payment would fail because the url would not match the
openid. maybe the blogging service could put the openid in the html
header for the bookmarklet to read?
cheers,
tom
On Jun 13, 1:57 am, HeresTomWithTheWeather
> http://www.opensourcecurrency.org/2010/06/opentransact-rel-payment-an...
>
> cheers,
> tom
>
> On Jun 12, 3:00 am, HeresTomWithTheWeather
>
>
>
> <herestomwiththeweat...@gmail.com> wrote:
> > it seems another option for user centric discovery might be the rel-
> > payment microformat for a hyperlink:
>
> >http://microformats.org/wiki/rel-payment
>
> > "RelPayment is a microformat for making exchanges of support (be it
> > financial or otherwise) possible. By adding rel="payment" to a
> > hyperlink a page indicates that the destination of that hyperlink
> > provides a way to show or give support for the current page. For
> > example to give financial support to the owner of the current page."
>
> > so, you could navigate to an openid page like a google profile (which
> > already allows its owner to add to a list of hyperlinks) and your
> > browser plugin could detect those opentransact links and display them
> > to you and you can choose which one to make payment to.
>
> > cheers,
> > tom
>
> > On May 19, 9:16 am, Pelle Braendgaard <pe...@stakeventures.com> wrote:
>
> > > Good point on the user centric discovery. For that I believe thehttp://xauth.orglikeapproachis probably the best. As I mentioned
> cheers,
> tom
>
> On Jun 12, 3:00 am, HeresTomWithTheWeather
>
>
>
> <herestomwiththeweat...@gmail.com> wrote:
> > it seems another option for user centric discovery might be the rel-
> > payment microformat for a hyperlink:
>
> >http://microformats.org/wiki/rel-payment
>
> > "RelPayment is a microformat for making exchanges of support (be it
> > financial or otherwise) possible. By adding rel="payment" to a
> > hyperlink a page indicates that the destination of that hyperlink
> > provides a way to show or give support for the current page. For
> > example to give financial support to the owner of the current page."
>
> > so, you could navigate to an openid page like a google profile (which
> > already allows its owner to add to a list of hyperlinks) and your
> > browser plugin could detect those opentransact links and display them
> > to you and you can choose which one to make payment to.
>
> > cheers,
> > tom
>
> > On May 19, 9:16 am, Pelle Braendgaard <pe...@stakeventures.com> wrote:
>
> > > before we could implement this on opentransact.org.
>
> > > How this works is that the user keeps his used currencies in his local
> > > storage under the opentransact.org domain.
>
> > > Providers and ecommerce sites write and read to this via a simple
> > > javascript API. I'll double check the license of the xauth javascript
> > > to see if we can build ontop of this.
>
> > > We still need a server centric discovery method as well for various
> > > other use cases.
>
> > > P
>
> > > On Wed, May 19, 2010 at 1:37 AM, Guillaume P. Lebleu
>
> > > <guilla...@lebleu.org> wrote:
> > > > Hi Pelle and thank you for following up on this.
>
> > > > My use case for this is a customer presenting an identifier to a merchant, allowing the merchant's agent to quickly figure which currencie(s) they both use, and the corresponding OpenTransact URL(s) to process the authorization. With regards to this scenario, your proposal seems issuer/host-centric, not user-centric: as a user, I will likely have various accounts at various issuers on multiple hosts.
>
> > > > That said, it is relevant for discovery in the context of Ripple-like discovery of currencies available at a host, and I think it raises some interesting questions.
>
> > > > For instance, If I'm a bank named "Banked of Trust" holding Fed reserves and issuing checking account money, is the name "Bank of Trust's US dollars" or "US dollars". Is the issuerhttp://federalreserve.govorhttp://bankoftrust.com?Iassume it's "Bank of Trust's US dollars" andhttp://bankoftrust.com, in which case, a unit may be useful, esp. in a Ripple context where you deal with different issuers issuing promises in the same unit.
>
> > > How this works is that the user keeps his used currencies in his local
> > > storage under the opentransact.org domain.
>
> > > Providers and ecommerce sites write and read to this via a simple
> > > javascript API. I'll double check the license of the xauth javascript
> > > to see if we can build ontop of this.
>
> > > We still need a server centric discovery method as well for various
> > > other use cases.
>
> > > P
>
> > > On Wed, May 19, 2010 at 1:37 AM, Guillaume P. Lebleu
>
> > > <guilla...@lebleu.org> wrote:
> > > > Hi Pelle and thank you for following up on this.
>
> > > > My use case for this is a customer presenting an identifier to a merchant, allowing the merchant's agent to quickly figure which currencie(s) they both use, and the corresponding OpenTransact URL(s) to process the authorization. With regards to this scenario, your proposal seems issuer/host-centric, not user-centric: as a user, I will likely have various accounts at various issuers on multiple hosts.
>
> > > > That said, it is relevant for discovery in the context of Ripple-like discovery of currencies available at a host, and I think it raises some interesting questions.
>
>
> > > >> --
> > > >> You received this message because you are subscribed to the Google Groups "agile-banking" group.
> > > >> To post to this group, send email to agile-...@googlegroups.com.
> > > >> To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
> > > >> For more options, visit this group athttp://groups.google.com/group/agile-banking?hl=en.
>
> > > > --
> > > > You received this message because you are subscribed to the Google Groups "agile-banking" group.
> > > > To post to this group, send email to agile-...@googlegroups.com.
> > > > To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
> > > > For more options, visit this group athttp://groups.google.com/group/agile-banking?hl=en.
>
> > > --http://agree2.com-ReachAgreement!http://stakeventures.com-Myblog about startups and agile banking
> > > >> --
> > > >> You received this message because you are subscribed to the Google Groups "agile-banking" group.
> > > >> To post to this group, send email to agile-...@googlegroups.com.
> > > >> To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
> > > >> For more options, visit this group athttp://groups.google.com/group/agile-banking?hl=en.
>
> > > > --
> > > > You received this message because you are subscribed to the Google Groups "agile-banking" group.
> > > > To post to this group, send email to agile-...@googlegroups.com.
> > > > To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
> > > > For more options, visit this group athttp://groups.google.com/group/agile-banking?hl=en.
>
Pelle Braendgaard
Jun 14, 2010, 10:34:51 PM6/14/10
to agile-...@googlegroups.com
Hey Tom,
Sorry I've been way to busy with client work. I did have a look at the
screencast and I think it's a great idea. This can be expanded
optionally to webfinger profiles as well using the same rel=payment.
Sorry I've been way to busy with client work. I did have a look at the
screencast and I think it's a great idea. This can be expanded
optionally to webfinger profiles as well using the same rel=payment.
I'll update my own blog with it in the next couple of days.
Pelle
> For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
>
>
--
http://agree2.com - Reach Agreement!
http://stakeventures.com - My blog about startups and agile banking
Reply all
Reply to author
Forward
0 new messages