Fwd: [rfc-dist] RFC 7033 on WebFinger

[Gonzalo Salgueiro (gsalguei)]

[Forgive the cross-post...]

Finally, we've arrived! Thanks to the many of you who generously contributed. An especially big shout out to Paul Jones for his passion and dedication, who as editor had the unenviable job of trying to appease everyone.

Cheers,

Gonzalo

Begin forwarded message:

> From: <rfc-e...@rfc-editor.org>
> Subject: [rfc-dist] RFC 7033 on WebFinger
> Date: September 27, 2013 5:37:11 PM EDT
> To: <ietf-a...@ietf.org>, <rfc-...@rfc-editor.org>
> Cc: <drafts-u...@iana.org>, <apps-d...@ietf.org>, <rfc-e...@rfc-editor.org>
>
> A new Request for Comments is now available in online RFC libraries.
>
>
> RFC 7033
>
> Title: WebFinger
> Author: P. Jones, G. Salgueiro,
> M. Jones, J. Smarr
> Status: Standards Track
> Stream: IETF
> Date: September 2013
> Mailbox: pau...@packetizer.com,
> gsal...@cisco.com,
> m...@microsoft.com,
> jsm...@google.com
> Pages: 28
> Characters: 61552
> Updates/Obsoletes/SeeAlso: None
>
> I-D Tag: draft-ietf-appsawg-webfinger-18.txt
>
> URL: http://www.rfc-editor.org/rfc/rfc7033.txt
>
> This specification defines the WebFinger protocol, which can be used
> to discover information about people or other entities on the
> Internet using standard HTTP methods. WebFinger discovers
> information for a URI that might not be usable as a locator
> otherwise, such as account or email URIs.
>
> This document is a product of the Applications Area Working Group Working Group of the IETF.
>
> This is now a Proposed Standard.
>
> STANDARDS TRACK: This document specifies an Internet standards track
> protocol for the Internet community,and requests discussion and suggestions
> for improvements. Please refer to the current edition of the Internet
> Official Protocol Standards (STD 1) for the standardization state and
> status of this protocol. Distribution of this memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
> http://www.ietf.org/mailman/listinfo/ietf-announce
> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
> For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
> For downloading RFCs, see http://www.rfc-editor.org/rfc.html
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-e...@rfc-editor.org. Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
>
> _______________________________________________
> rfc-dist mailing list
> rfc-...@rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-dist
> http://www.rfc-editor.org

[Mike Jones]

FYI, I've posted about this at http://self-issued.info/?p=1125 and on Twitter as @selfissued.

Have a good weekend, everyone!

-- Mike

_______________________________________________
apps-discuss mailing list
apps-d...@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

[Melvin Carvalho]

On 28 September 2013 00:09, Gonzalo Salgueiro (gsalguei) <gsal...@cisco.com> wrote:

[Forgive the cross-post...]

Finally, we've arrived!   Thanks to the many of you who generously contributed.  An especially big shout out to Paul Jones for his passion and dedication, who as editor had the unenviable job of trying to appease everyone.

+1

Congrats!  And thanks to Paul also.

My two main hopes for the spec were to move from XML to JSON (done!) and to make the acct: URI scheme optional (done!). 

I look forward to seeing how this technology is deployed including outside of the OpenID use case.

My thoughts currently are that JRD seems great for many use cases, but for some advanced use cases (for me im interested in social and commerce) I may use a different type of JSON depending on the need, the spec allows this which is great.

It will take time to see if acct: catches on as a global pattern in the same way that http: and mailto: have.  I like to keep long lived identifiers for systems I build, so there's a degree of guess work there.  Personally I'm going to stick to mailto: but watch and see if acct: catches on, then think about switching. 

It's great finally to have a solution that gives us meta data from an email address, I think this has been a missing piece of the web for some time!

 

--

---
You received this message because you are subscribed to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Paul E. Jones]

Melvin,

 

I look forward to seeing how this technology is deployed including outside of the OpenID use case.

 

Me, too.  There are plenty of use cases and I have some expectations for WebFinger that I hope do result in product features.  During the weekend, I thought that using WebFinger as a means of sending Bitcoins would be very cool.  See: http://www.packetizer.com/people/paulej/blog/53

 

My thoughts currently are that JRD seems great for many use cases, but for some advanced use cases (for me im interested in social and commerce) I may use a different type of JSON depending on the need, the spec allows this which is great.

 

I do hope that you do not introduce a lot of stuff that substantially changes the JRD.  I'm not sure what more advanced things you want to do, but if you have a need for a lot of different data members, it might be better to refer to another document.

 

It will take time to see if acct: catches on as a global pattern in the same way that http: and mailto: have.  I like to keep long lived identifiers for systems I build, so there's a degree of guess work there.  Personally I'm going to stick to mailto: but watch and see if acct: catches on, then think about switching.

 

It will take time for WebFinger to gain widespread use, but I would strongly encourage use of "acct" from the outset.  Using "mailto" is certainly possible, but if the objective is to identify a user's account and we cannot reach agreement on what the account identifier is, that's a problem.  What would be the reason for using the "mailto" scheme when referring to a user account?  Now, if you really want information about the email address, the "mailto" might be appropriate.

 

 It's great finally to have a solution that gives us meta data from an email address, I think this has been a missing piece of the web for some time!

 

Agreed.  This is one more piece to building a programmable web and making the Internet that much more useful.

 

Paul

 

[Melvin Carvalho]

On 2 October 2013 17:10, Paul E. Jones <pau...@packetizer.com> wrote:

Melvin,

 

I look forward to seeing how this technology is deployed including outside of the OpenID use case.

 

Me, too.  There are plenty of use cases and I have some expectations for WebFinger that I hope do result in product features.  During the weekend, I thought that using WebFinger as a means of sending Bitcoins would be very cool.  See: http://www.packetizer.com/people/paulej/blog/53

Nice idea, however

http://bitcoin.org/rel/address 

Doesnt seem to dereference. 

 

My thoughts currently are that JRD seems great for many use cases, but for some advanced use cases (for me im interested in social and commerce) I may use a different type of JSON depending on the need, the spec allows this which is great.

 

I do hope that you do not introduce a lot of stuff that substantially changes the JRD.  I'm not sure what more advanced things you want to do, but if you have a need for a lot of different data members, it might be better to refer to another document.

My main interests are the social web and payments.  JRD is great for a lot of use cases but there are some things it cant handle as easily as other serializations.  For example, unordered lists of links (e.g. friends).  Also for finance I tend to use numbers in transactions, and JRD can only handle strings.  I dont expect JRD to change notably, so there would perhaps be other ways to handle such cases.

 

 

It will take time to see if acct: catches on as a global pattern in the same way that http: and mailto: have.  I like to keep long lived identifiers for systems I build, so there's a degree of guess work there.  Personally I'm going to stick to mailto: but watch and see if acct: catches on, then think about switching.

 

It will take time for WebFinger to gain widespread use, but I would strongly encourage use of "acct" from the outset.  Using "mailto" is certainly possible, but if the objective is to identify a user's account and we cannot reach agreement on what the account identifier is, that's a problem.  What would be the reason for using the "mailto" scheme when referring to a user account?  Now, if you really want information about the email address, the "mailto" might be appropriate.

There's no consensus on which string is a primary key for identity (unfortunately) on the net today.  Some prefer http profiles, some prefer email addresses, some prefer public keys, some prefer acct: URIs, and perhaps in future telephone number will become more popular.  acct: will take some time to pick up.  My use case for webfinger is to add meta data to email type addresses, so mailto is a well deployed candidate for that.  On the client side, I'll probably be handling acct: too.  If acct: really takes off I can spend more time handling that type of identifier, but we'll only know given time.

 

 

 It's great finally to have a solution that gives us meta data from an email address, I think this has been a missing piece of the web for some time!

 

Agreed.  This is one more piece to building a programmable web and making the Internet that much more useful.

 

Paul

 

--

[Paul E. Jones]

Melvin,

On 2 October 2013 17:10, Paul E. Jones <pau...@packetizer.com> wrote:

Melvin,

 

I look forward to seeing how this technology is deployed including outside of the OpenID use case.

 

Me, too.  There are plenty of use cases and I have some expectations for WebFinger that I hope do result in product features.  During the weekend, I thought that using WebFinger as a means of sending Bitcoins would be very cool.  See: http://www.packetizer.com/people/paulej/blog/53

Nice idea, however

http://bitcoin.org/rel/address 

Doesnt seem to dereference. 

 

I just made that up.  It's only to demonstrate the possibility.  I also made up the "payments" link relation values, too.  The idea with the payments link relation is that the URL there would point to a location where a client would query with HTTP to get the payment address.  These would not necessarily even have to be two link relation types, since the client could see one is an HTTP href and dereference it.  In any case, I threw this out there for people to chew on.  I don't think folks in the Bitcoin community have really taken a good look at this.  WebFinger really has to get deployed first.  It's also not a priority, since Bitcoin users are happy with using QR codes and copying and pasting those long 35 character Bitcoin addresses.  The average user isn't going to like that, though, so they do need something a little more user friendly.

 

 

My thoughts currently are that JRD seems great for many use cases, but for some advanced use cases (for me im interested in social and commerce) I may use a different type of JSON depending on the need, the spec allows this which is great.

 

I do hope that you do not introduce a lot of stuff that substantially changes the JRD.  I'm not sure what more advanced things you want to do, but if you have a need for a lot of different data members, it might be better to refer to another document.

My main interests are the social web and payments.  JRD is great for a lot of use cases but there are some things it cant handle as easily as other serializations.  For example, unordered lists of links (e.g. friends).  Also for finance I tend to use numbers in transactions, and JRD can only handle strings.  I dont expect JRD to change notably, so there would perhaps be other ways to handle such cases.

 

For those things, though, why would they be in WebFinger itself?  For example, if you wish to have a list of friends, it would seem that WF would be useful to discover the location of the friend list, but the friend list itself would be in whatever format is most suitable.

 

 

It will take time to see if acct: catches on as a global pattern in the same way that http: and mailto: have.  I like to keep long lived identifiers for systems I build, so there's a degree of guess work there.  Personally I'm going to stick to mailto: but watch and see if acct: catches on, then think about switching.

 

It will take time for WebFinger to gain widespread use, but I would strongly encourage use of "acct" from the outset.  Using "mailto" is certainly possible, but if the objective is to identify a user's account and we cannot reach agreement on what the account identifier is, that's a problem.  What would be the reason for using the "mailto" scheme when referring to a user account?  Now, if you really want information about the email address, the "mailto" might be appropriate.

There's no consensus on which string is a primary key for identity (unfortunately) on the net today.  Some prefer http profiles, some prefer email addresses, some prefer public keys, some prefer acct: URIs, and perhaps in future telephone number will become more popular.  acct: will take some time to pick up.  My use case for webfinger is to add meta data to email type addresses, so mailto is a well deployed candidate for that.  On the client side, I'll probably be handling acct: too.  If acct: really takes off I can spend more time handling that type of identifier, but we'll only know given time.

 

It was this very reason that "acct" grew legs and became its own thing.  There was a desire to have something that was familiar to people and easily understood, but it's not an email address.  The "mailto" URI also has a whole lot of baggage that goes with it that makes it just that much more complicated.  For example, one can include a subject line, multiple "to" addresses, etc.  So, what does WF do with "mailto:pau...@packetizer.com,j...@example.com?subject=Now%20What?" This scheme can be cranky.  Plus, you need something for social networks and there people have accounts.  The acct URI is a really good fit, because it has the familiar look of the email address and would should really be equated by the human user as the same identifier.  It's just the WF client and server that look at the URI scheme.

 

Paul

 

[Melvin Carvalho]

On 9 October 2013 04:50, Paul E. Jones <pau...@packetizer.com> wrote:

Melvin,

On 2 October 2013 17:10, Paul E. Jones <pau...@packetizer.com> wrote:

Melvin,

 

I look forward to seeing how this technology is deployed including outside of the OpenID use case.

 

Me, too.  There are plenty of use cases and I have some expectations for WebFinger that I hope do result in product features.  During the weekend, I thought that using WebFinger as a means of sending Bitcoins would be very cool.  See: http://www.packetizer.com/people/paulej/blog/53

Nice idea, however

http://bitcoin.org/rel/address 

Doesnt seem to dereference. 

 

I just made that up.  It's only to demonstrate the possibility.  I also made up the "payments" link relation values, too.  The idea with the payments link relation is that the URL there would point to a location where a client would query with HTTP to get the payment address.  These would not necessarily even have to be two link relation types, since the client could see one is an HTTP href and dereference it.  In any case, I threw this out there for people to chew on.  I don't think folks in the Bitcoin community have really taken a good look at this.  WebFinger really has to get deployed first.  It's also not a priority, since Bitcoin users are happy with using QR codes and copying and pasting those long 35 character Bitcoin addresses.  The average user isn't going to like that, though, so they do need something a little more user friendly.

Got it.

Normally it's something of a best practice to put a bunch of terms in a single document so that you only have at dereference it once to find out all the meanings.

As it happens, I should be the person maintaining the bitcoin schema, so I could add something like this upstream :)

 

 

 

My thoughts currently are that JRD seems great for many use cases, but for some advanced use cases (for me im interested in social and commerce) I may use a different type of JSON depending on the need, the spec allows this which is great.

 

I do hope that you do not introduce a lot of stuff that substantially changes the JRD.  I'm not sure what more advanced things you want to do, but if you have a need for a lot of different data members, it might be better to refer to another document.

My main interests are the social web and payments.  JRD is great for a lot of use cases but there are some things it cant handle as easily as other serializations.  For example, unordered lists of links (e.g. friends).  Also for finance I tend to use numbers in transactions, and JRD can only handle strings.  I dont expect JRD to change notably, so there would perhaps be other ways to handle such cases.

 

For those things, though, why would they be in WebFinger itself?  For example, if you wish to have a list of friends, it would seem that WF would be useful to discover the location of the friend list, but the friend list itself would be in whatever format is most suitable.

You can do that too, but it's one extra round trip, is the only thing.

 

 

 

It will take time to see if acct: catches on as a global pattern in the same way that http: and mailto: have.  I like to keep long lived identifiers for systems I build, so there's a degree of guess work there.  Personally I'm going to stick to mailto: but watch and see if acct: catches on, then think about switching.

 

It will take time for WebFinger to gain widespread use, but I would strongly encourage use of "acct" from the outset.  Using "mailto" is certainly possible, but if the objective is to identify a user's account and we cannot reach agreement on what the account identifier is, that's a problem.  What would be the reason for using the "mailto" scheme when referring to a user account?  Now, if you really want information about the email address, the "mailto" might be appropriate.

There's no consensus on which string is a primary key for identity (unfortunately) on the net today.  Some prefer http profiles, some prefer email addresses, some prefer public keys, some prefer acct: URIs, and perhaps in future telephone number will become more popular.  acct: will take some time to pick up.  My use case for webfinger is to add meta data to email type addresses, so mailto is a well deployed candidate for that.  On the client side, I'll probably be handling acct: too.  If acct: really takes off I can spend more time handling that type of identifier, but we'll only know given time.

 

It was this very reason that "acct" grew legs and became its own thing.  There was a desire to have something that was familiar to people and easily understood, but it's not an email address.  The "mailto" URI also has a whole lot of baggage that goes with it that makes it just that much more complicated.  For example, one can include a subject line, multiple "to" addresses, etc.  So, what does WF do with "mailto:pau...@packetizer.com,j...@example.com?subject=Now%20What?" This scheme can be cranky.  Plus, you need something for social networks and there people have accounts.  The acct URI is a really good fit, because it has the familiar look of the email address and would should really be equated by the human user as the same identifier.  It's just the WF client and server that look at the URI scheme.

Sure, I get this.  But the original use case of webfinger (about 5 years ago) was to get meta data about email.  That it can do accounts too is great, it's just that as a relatively new URI scheme, you often need a bit of time to see how heavily deployed it gets.

[Paul E. Jones]

Melvin,

I just made that up.  It's only to demonstrate the possibility.  I also made up the "payments" link relation values, too.  The idea with the payments link relation is that the URL there would point to a location where a client would query with HTTP to get the payment address.  These would not necessarily even have to be two link relation types, since the client could see one is an HTTP href and dereference it.  In any case, I threw this out there for people to chew on.  I don't think folks in the Bitcoin community have really taken a good look at this.  WebFinger really has to get deployed first.  It's also not a priority, since Bitcoin users are happy with using QR codes and copying and pasting those long 35 character Bitcoin addresses.  The average user isn't going to like that, though, so they do need something a little more user friendly.

Got it.

Normally it's something of a best practice to put a bunch of terms in a single document so that you only have at dereference it once to find out all the meanings.

As it happens, I should be the person maintaining the bitcoin schema, so I could add something like this upstream :)

Wow, that would be awesome!  I think the idea behind Bitcoin is good, as it has the potential for simplifying the payment process (especially online) and removes the risks merchants face every time they accept a credit card.  The only "ugly" part of using Bitcoin, IMO, is the complex addressing scheme.  For me and you, it's not a big deal, but it's not all all intuitive to the average person. 

My main interests are the social web and payments.  JRD is great for a lot of use cases but there are some things it cant handle as easily as other serializations.  For example, unordered lists of links (e.g. friends).  Also for finance I tend to use numbers in transactions, and JRD can only handle strings.  I dont expect JRD to change notably, so there would perhaps be other ways to handle such cases.

 For those things, though, why would they be in WebFinger itself?  For example, if you wish to have a list of friends, it would seem that WF would be useful to discover the location of the friend list, but the friend list itself would be in whatever format is most suitable.

You can do that too, but it's one extra round trip, is the only thing.

That's true, but trying to put a significant amount of data into a WF response can introduce problems of its own.  If every application (e.g., vcard) was inserted into WebFinger, the JRD would be enormous. 

It was this very reason that "acct" grew legs and became its own thing.  There was a desire to have something that was familiar to people and easily understood, but it's not an email address.  The "mailto" URI also has a whole lot of baggage that goes with it that makes it just that much more complicated.  For example, one can include a subject line, multiple "to" addresses, etc.  So, what does WF do with "mailto:pau...@packetizer.com,j...@example.com?subject=Now%20What?" This scheme can be cranky.  Plus, you need something for social networks and there people have accounts.  The acct URI is a really good fit, because it has the familiar look of the email address and would should really be equated by the human user as the same identifier.  It's just the WF client and server that look at the URI scheme.

Sure, I get this.  But the original use case of webfinger (about 5 years ago) was to get meta data about email.  That it can do accounts too is great, it's just that as a relatively new URI scheme, you often need a bit of time to see how heavily deployed it gets.

You're correct about the history, however using email: with WF is also a new deployment; it's re-purposing the schema for use in a different application.  There's nothing wrong with that, but it's not the most ideal solution, IMO.  Given that RFC 7033 is brand new and any implementations would be relatively new, I'd really like to encourage use of acct from the outset so we don't have to deal with interoperability issues where some opted to use mailto: and some opted to use acct: to refer to WF information about a human user.  Let's get started on the right foot :-)

 

Paul

 

[Melvin Carvalho]

On 10 October 2013 01:21, Paul E. Jones <pau...@packetizer.com> wrote:

Melvin,

I just made that up.  It's only to demonstrate the possibility.  I also made up the "payments" link relation values, too.  The idea with the payments link relation is that the URL there would point to a location where a client would query with HTTP to get the payment address.  These would not necessarily even have to be two link relation types, since the client could see one is an HTTP href and dereference it.  In any case, I threw this out there for people to chew on.  I don't think folks in the Bitcoin community have really taken a good look at this.  WebFinger really has to get deployed first.  It's also not a priority, since Bitcoin users are happy with using QR codes and copying and pasting those long 35 character Bitcoin addresses.  The average user isn't going to like that, though, so they do need something a little more user friendly.

Got it.

Normally it's something of a best practice to put a bunch of terms in a single document so that you only have at dereference it once to find out all the meanings.

As it happens, I should be the person maintaining the bitcoin schema, so I could add something like this upstream :)

Wow, that would be awesome!  I think the idea behind Bitcoin is good, as it has the potential for simplifying the payment process (especially online) and removes the risks merchants face every time they accept a credit card.  The only "ugly" part of using Bitcoin, IMO, is the complex addressing scheme.  For me and you, it's not a big deal, but it's not all all intuitive to the average person. 

Done!

You can use the following link to indicate a bitcoin address.  I'm working with the bitcoin community to add other currencies (e.g. litecoin, ppcoin) shortly

https://w3id.org/cc#bitcoin

Full vocab is at:

https://w3id.org/cc

 

My main interests are the social web and payments.  JRD is great for a lot of use cases but there are some things it cant handle as easily as other serializations.  For example, unordered lists of links (e.g. friends).  Also for finance I tend to use numbers in transactions, and JRD can only handle strings.  I dont expect JRD to change notably, so there would perhaps be other ways to handle such cases.

 For those things, though, why would they be in WebFinger itself?  For example, if you wish to have a list of friends, it would seem that WF would be useful to discover the location of the friend list, but the friend list itself would be in whatever format is most suitable.

You can do that too, but it's one extra round trip, is the only thing.

That's true, but trying to put a significant amount of data into a WF response can introduce problems of its own.  If every application (e.g., vcard) was inserted into WebFinger, the JRD would be enormous. 

It was this very reason that "acct" grew legs and became its own thing.  There was a desire to have something that was familiar to people and easily understood, but it's not an email address.  The "mailto" URI also has a whole lot of baggage that goes with it that makes it just that much more complicated.  For example, one can include a subject line, multiple "to" addresses, etc.  So, what does WF do with "mailto:pau...@packetizer.com,j...@example.com?subject=Now%20What?" This scheme can be cranky.  Plus, you need something for social networks and there people have accounts.  The acct URI is a really good fit, because it has the familiar look of the email address and would should really be equated by the human user as the same identifier.  It's just the WF client and server that look at the URI scheme.

Sure, I get this.  But the original use case of webfinger (about 5 years ago) was to get meta data about email.  That it can do accounts too is great, it's just that as a relatively new URI scheme, you often need a bit of time to see how heavily deployed it gets.

You're correct about the history, however using email: with WF is also a new deployment; it's re-purposing the schema for use in a different application.  There's nothing wrong with that, but it's not the most ideal solution, IMO.  Given that RFC 7033 is brand new and any implementations would be relatively new, I'd really like to encourage use of acct from the outset so we don't have to deal with interoperability issues where some opted to use mailto: and some opted to use acct: to refer to WF information about a human user.  Let's get started on the right foot :-)

 

Paul

 

--

[Paul E. Jones]

Melvin,

To advertise a Bitcoin address or payment URL, we need to define a link relation type.  Are you defining "bitcoin" to be that link relation or is it https://cc.rww.io/vocab#bitcoin?  I didn't see anything on either of those links that would have provided me with a hint that ether is the "link relation type" to use in either a web page or WebFinger.

Paul

[Melvin Carvalho]

On 11 October 2013 20:06, Paul E. Jones <pau...@packetizer.com> wrote:

Melvin,

To advertise a Bitcoin address or payment URL, we need to define a link relation type.  Are you defining "bitcoin" to be that link relation or is it https://cc.rww.io/vocab#bitcoin?  I didn't see anything on either of those links that would have provided me with a hint that ether is the "link relation type" to use in either a web page or WebFinger.

All you need to do is put "https://w3id.org/cc#bitcoin" in your webfinger links array.

A full record may look something like this:

     {
       "subject" : "acct:pa...@packetizer.com",
       "links" :
       [
         {
           "rel" : "https://w3id.org/cc#bitcoin",
           "href" : "bitcoin:15WFfLUjhyJqwiPzWeM6PrXFrJCNSwZ2cS"
         }
       ]
     }

For reference the vocab has the following description currenty (but you dont need to worry about this)

type Datatype Property comment This represents a bitcoin address which should be a bitcoin: URI

 

Paul

On 10/11/2013 11:33 AM, Melvin Carvalho wrote:

Wow, that would be awesome!  I think the idea behind Bitcoin is good, as it has the potential for simplifying the payment process (especially online) and removes the risks merchants face every time they accept a credit card.  The only "ugly" part of using Bitcoin, IMO, is the complex addressing scheme.  For me and you, it's not a big deal, but it's not all all intuitive to the average person. 

Done!

You can use the following link to indicate a bitcoin address.  I'm working with the bitcoin community to add other currencies (e.g. litecoin, ppcoin) shortly

https://w3id.org/cc#bitcoin

Full vocab is at:

https://w3id.org/cc

[Paul E. Jones]

Melvin,

On 10/11/2013 3:09 PM, Melvin Carvalho wrote:

On 11 October 2013 20:06, Paul E. Jones <pau...@packetizer.com> wrote:

Melvin,

To advertise a Bitcoin address or payment URL, we need to define a link relation type.  Are you defining "bitcoin" to be that link relation or is it https://cc.rww.io/vocab#bitcoin?  I didn't see anything on either of those links that would have provided me with a hint that ether is the "link relation type" to use in either a web page or WebFinger.

All you need to do is put "https://w3id.org/cc#bitcoin" in your webfinger links array.

From reading the web page, I never would have guessed this URI.  I think it would be beneficial if the web page actually provided the fully-qualified URI.

As for the particular URI to use, what I had suggested was http://bitcoin.org/rel/address.  The reason for that suggestion is that the domain is owned by the Bitcoin Foundation.  Since I'm not a core person in the Bitcoin community, I obviously cannot speak for them.  But, it makes sense to me that the identifier should be officially accepted.  Have you reached out to them?

Paul

[Melvin Carvalho]

On 11 October 2013 23:40, Paul E. Jones <pau...@packetizer.com> wrote:

Melvin,

On 10/11/2013 3:09 PM, Melvin Carvalho wrote:

On 11 October 2013 20:06, Paul E. Jones <pau...@packetizer.com> wrote:

Melvin,

To advertise a Bitcoin address or payment URL, we need to define a link relation type.  Are you defining "bitcoin" to be that link relation or is it https://cc.rww.io/vocab#bitcoin?  I didn't see anything on either of those links that would have provided me with a hint that ether is the "link relation type" to use in either a web page or WebFinger.

All you need to do is put "https://w3id.org/cc#bitcoin" in your webfinger links array.

From reading the web page, I never would have guessed this URI.  I think it would be beneficial if the web page actually provided the fully-qualified URI.

Sure, I only put this together in the last day after you requested, documentation is in progress.

Im unsure what you mean by fully qualified URI.

 

As for the particular URI to use, what I had suggested was http://bitcoin.org/rel/address.  The reason for that suggestion is that the domain is owned by the Bitcoin Foundation.  Since I'm not a core person in the Bitcoin community, I obviously cannot speak for them.  But, it makes sense to me that the identifier should be officially accepted.  Have you reached out to them?

Yes, I've spoken to the bitcoin folks a lot, there were some issues with upload and maintenance.  Also we slightly prefer https for financial things, and w3id.org is where much of the upcoming W3C payments vocabs will be hosted.

 

Paul

[Paul E. Jones]

On 10/11/2013 5:47 PM, Melvin Carvalho wrote:

From reading the web page, I never would have guessed this URI.  I think it would be beneficial if the web page actually provided the fully-qualified URI.

Sure, I only put this together in the last day after you requested, documentation is in progress.

Im unsure what you mean by fully qualified URI.

What I meant was that visiting that page to which you referred, I never would have determined that the URI you're suggesting to use is "https://w3id.org/cc#bitcoin".  All I saw was "bitcoin" outside the context of anything.

Paul

[Melvin Carvalho]

Sure, this will all all be documented shortly.  What's relevant to WF is that you can now add a bitcoin address to your record using the following markup:

     {
       "subject" : "acct:pa...@packetizer.com",
       "links" :
       [
         {
           "rel" : "https://w3id.org/cc#bitcoin",
           "href" : "bitcoin:15WFfLUjhyJqwiPzWeM6PrXFrJCNSwZ2cS"

         }
       ]
     }

Note: the first entry in the array with be considered your 'preferred' address.