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:
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".
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:
-- You received this message because you are subscribed to the Google Groups "agile-banking" group.
To post to this group, send email to agile-banking@googlegroups.com.
To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
> 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:
> 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".
> 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:
> --
> You received this message because you are subscribed to the Google Groups
> "agile-banking" group.
> To post to this group, send email to agile-banking@googlegroups.com.
> To unsubscribe from this group, send email to
> agile-banking+unsubscribe@googlegroups.com<agile-banking%2Bunsubscribe@goog legroups.com>
> .
> For more options, visit this group at
> http://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-banking@googlegroups.com.
To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
> wrote:
> you mean opentransact assets, not openid assets right?
> -tom
> On Mon, May 17, 2010 at 10:04 PM, Pelle Braendgaard <pe...@stakeventures.com > > 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:
> 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".
> 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:
> --
> You received this message because you are subscribed to the Google
> Groups "agile-banking" group.
> To post to this group, send email to agile-banking@googlegroups.com.
> To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://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-banking@googlegroups.com.
> To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://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-banking@googlegroups.com.
To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
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
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:
> 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".
> 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:
> -- > You received this message because you are subscribed to the Google Groups "agile-banking" group.
> To post to this group, send email to agile-banking@googlegroups.com.
> To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
> For more options, visit this group at http://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-banking@googlegroups.com.
To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
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
On May 18, 2010, at 10:37 PM, Guillaume P. Lebleu 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 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
> 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:
>> 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".
>> 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:
>> -- >> You received this message because you are subscribed to the Google Groups "agile-banking" group.
>> To post to this group, send email to agile-banking@googlegroups.com.
>> To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://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-banking@googlegroups.com.
> To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
> For more options, visit this group at http://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-banking@googlegroups.com.
To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
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:
> 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
> 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:
>> 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".
>> 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:
>> -- >> You received this message because you are subscribed to the Google Groups "agile-banking" group.
>> To post to this group, send email to agile-banking@googlegroups.com.
>> To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://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-banking@googlegroups.com.
> To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
> For more options, visit this group at http://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-banking@googlegroups.com.
To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
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
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 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
> 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:
>> 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".
>> 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:
>> --
>> You received this message because you are subscribed to the Google Groups "agile-banking" group.
>> To post to this group, send email to agile-banking@googlegroups.com.
>> To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://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-banking@googlegroups.com.
> To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
> For more options, visit this group at http://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-banking@googlegroups.com.
To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
"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.
> > 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:
> >> 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".
> >> 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:
> >> --
> >> You received this message because you are subscribed to the Google Groups "agile-banking" group.
> >> To post to this group, send email to agile-banking@googlegroups.com.
> >> To unsubscribe from this group, send email to agile-banking+unsubscribe@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-banking@googlegroups.com.
> > To unsubscribe from this group, send email to agile-banking+unsubscribe@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-banking@googlegroups.com.
> To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/agile-banking?hl=en.
<herestomwiththeweat...@gmail.com> wrote:
> it seems another option for user centric discovery might be the rel-
> payment microformat for a hyperlink:
> "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
> > 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.
> > > 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:
> > >> 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".
> > >> 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:
> > >> --
> > >> You received this message because you are subscribed to the Google Groups "agile-banking" group.
> > >> To post to this group, send email to agile-banking@googlegroups.com.
> > >> To unsubscribe from this group, send email to agile-banking+unsubscribe@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-banking@googlegroups.com.
> > > To unsubscribe from this group, send email to agile-banking+unsubscribe@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-banking@googlegroups.com.
> > To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/agile-banking?hl=en.
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?
> <herestomwiththeweat...@gmail.com> wrote:
> > it seems another option for user centric discovery might be the rel-
> > payment microformat for a hyperlink:
> > "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
> > > 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.
> > > > 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:
> > > >> 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".
> > > >> 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:
> > > >> --
> > > >> You received this message because you are subscribed to the Google Groups "agile-banking" group.
> > > >> To post to this group, send email to agile-banking@googlegroups.com.
> > > >> To unsubscribe from this group, send email to agile-banking+unsubscribe@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-banking@googlegroups.com.
> > > > To unsubscribe from this group, send email to agile-banking+unsubscribe@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-banking@googlegroups.com.
> > > To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/agile-banking?hl=en.
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.
I'll update my own blog with it in the next couple of days.
Pelle
On Mon, Jun 14, 2010 at 7:57 PM, HeresTomWithTheWeather
<herestomwiththeweat...@gmail.com> wrote: > 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 > <herestomwiththeweat...@gmail.com> wrote: >> i did a screencast to demonstrate rel-payment:
>> <herestomwiththeweat...@gmail.com> wrote: >> > it seems another option for user centric discovery might be the rel- >> > payment microformat for a hyperlink:
>> > "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 >> > > 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.
>> > > > 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:
>> > > >> 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".
>> > > >> 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:
>> > > >> -- >> > > >> You received this message because you are subscribed to the Google Groups "agile-banking" group. >> > > >> To post to this group, send email to agile-banking@googlegroups.com. >> > > >> To unsubscribe from this group, send email to agile-banking+unsubscribe@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-banking@googlegroups.com. >> > > > To unsubscribe from this group, send email to agile-banking+unsubscribe@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-banking@googlegroups.com. >> > > To unsubscribe from this group, send email to agile-banking+unsubscribe@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-banking@googlegroups.com. > To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
