I took a quick look at the eastlake draft from 2001 and although I wasn't watching those discussions here are my observations:
- This was prior to the supporting work of DNSSEC and DANE which provide an established trust anchor and chain of trust. This looks as though it was an idea before its time :) - Their proposal used the DNS hierarchy rooted in a single TLD to locate the records. There are significant advantages to following the more familiar model in the DNS of expecting RR sets within the domain associated with the target entity (I go to google.com to find records related to google) rather than capturing application usages within a TLD. - Their security considerations beg the question of DNSSEC and the work being done in DPRIV! - I suspect that some of the work in the eastlake draft may be relevant to this proposal and I want to digest it more completely to see what we might leverage. I'd love to hear relevant thoughts form the discussions in 2001 if any of those folks are on the list. thanks Glen ________________________________ From: dane [[email protected]] on behalf of Falcon Darkstar Momot [[email protected]] Sent: Wednesday, March 11, 2015 3:35 AM To: [email protected] Subject: Re: [dane] Payment association records I lightly draw attention to an ancient failed internet draft for storing substantive payment processing information in the DNS: https://tools.ietf.org/html/draft-eastlake-card-map-08 I also draw attention for a different reason to the yet-reserved HTTP status code 402 (https://tools.ietf.org/html/rfc7231#page-59). --Falcon Darkstar Momot --Shadytel On 10/03/2015 15:21, Wiley, Glen wrote: A few of us have put some work into an 00 draft describing a DANE like RR that would provide an association for payment information via the DNS. The abstract from the draft reads: There is no standard, interoperable method for associating Internet service identifiers with payment information. This document specifies a means for retrieving information sufficient for a party to render payment using various payment networks given the recipient's email address by leveraging the DNS to securely publish payment information in a payment association record. A payment association record associates an Internet service identifier such as an email address with payment information such as an account number or Bitcoin address. Our draft is in the tracker: https://tools.ietf.org/html/draft-wiley-paymentassoc-00 And I’d like to get some feedback from folks on this to see what we can do to make this an effective tool. There are a number of elements that need to be fleshed out and we have more content in the works to address specific use cases. Looking forward to hearing from folks. -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A _______________________________________________ dane mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dane
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
