- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Thu, 3 Sep 2015 18:05:12 +0200
- To: KETELS Kris <Kris.KETELS@swift.com>
- Cc: Evert Fekkes <E.R.Fekkes@rn.rabobank.nl>, Adrian Hope-Bailie <adrian@ripple.com>, Kepeng Li <kepeng.lkp@alibaba-inc.com>, "Adler, Patrick" <patrick.adler@chi.frb.org>, VIGNET cyril <Cyril.VIGNET@bpce.fr>, "j.j.spaanderman@dnb.nl" <j.j.spaanderman@dnb.nl>, Web Payments IG <public-webpayments-ig@w3.org>, Ian Jacobs <ij@w3.org>
- Message-ID: <CA+eFz_Jkys6p2cU6rgC+LpBpbOWJkO8-8A4NMYbxMKnZ24+tTg@mail.gmail.com>
On 3 September 2015 at 17:36, KETELS Kris <Kris.KETELS@swift.com> wrote: > Dear Adrian, dear Evert, > > > > Building on this: at this stage, ISO 20022 only supports XML and ASN.1. > The standard however was designed to be extensible for other syntaxes if > need be. For this reason, as we speak, ISO 20022 is looking into extending > the ISO 20022 specification to support API’s and as such, also JSON which > is becoming the predominant syntax for API’s. > > The goal being that from a single logical model, it should be possible to > generate for example both an XML message and its JSON equivalent. > Great! For better or worse JSON is the serialisation that has become ubiquitous on the Web. > > > Maybe some more things on ISO 20022 itself: it is correct the > specification itself is payable (i.e. the metamodel, the transformation > rules to XML, the modelling guidelines etc...) but the actual Message > Definitions are free of charge and can be downloaded from the ISO 20022 > website (http://www.iso20022.org/). There you will also be able to obtain > an electronic version of the repository which for example contains the data > dictionary describing all of the business and message concepts used in ISO > 20022). > > > We couldn't get this right a few months back so perhaps with your help we can resolve that. > > > Kind regards > > Kris > > > > > > *From:* Adrian Hope-Bailie [mailto:adrian@hopebailie.com] > *Sent:* 03 September 2015 14:20 > *To:* Evert Fekkes > *Cc:* Adrian Hope-Bailie; KETELS Kris; Kepeng Li; Adler, Patrick; VIGNET > cyril; j.j.spaanderman@dnb.nl; Web Payments IG; Ian Jacobs > > *Subject:* Re: Organize a chat on account/ledger capabilities? > > > > Hi Evert, > > Good points but I think fundamentally the W3C has evolved in a world where > developer-centric processes are favoured and ISO favours large > organisations and governments. > > > > On 3 September 2015 at 08:49, <E.R.Fekkes@rn.rabobank.nl> wrote: > > Hello Adrian, > > > > Well worded response, of which I recognize quite a lot. > > Some comments, though: > > > > · ISO standards must be paid for, but do you think the cost is > prohibitive? > I think ISO has a different business model as W3C, but for ISO my > organization does not have to pay a (substantial) membership fee. > > I do. The majority of W3C standards I look at I do so as part of my > research. Only quite far into the process would I need them as a definitive > reference and be prepared to pay for them. > > For a small dev shop paying for every spec is a non-starter. Access to the > specs is also not reserved for members. Organisations become members of W3C > to support the consortium's work and to have input into the development of > standards not for any privileged access to the specs. > > > > · In my opinion, we should make use of ISO and other work as > components. ISO 20022 is surely a given and could be extended with JSON > formats next to XML and ASN.1. > > Absolutely. My one concern about ISO20022 is that the messaging seems to > be very use case specific. i.e. There is a message definition for each use > case and these definitions are extensive. > > I suspect we will be looking to define our standards at a higher level of > abstraction with a minimal set of required fields and an extensible format > since that's how the Web works and most successful Web standards have > evolved. > > > > There was some effort from Erik and others to get a comprehensive > dictionary from ISO20022 as a basis for our vocabulary but I think the > result was that this simply doesn't exist. > > ISO 8583 is gradually on it’s way out, but we have to keep in mind that > many processing systems are firmly based on this standard and migration > will take 5-10 years. Other standards such as security, connectivity (NFC) > are necessary elements as well. > > ISO8383 is dead. Long live ISO8583 :) > > The rate of innovation on the Web is certainly unmatched in most other > ecosystems. That's probabaly why the "FinTech revoluton" is taking place as > technology spills into industries that have not evolved as fast as they > could have. > > I like our approach of dealing with friction points and interoperability > and letting the existing schemes (like card and others based on dinosaur > technology) operate within those new paradigms but at the same time > allowing new schemes to evolve that are more suited to the Web architecture. > > > · The W3C WPAY must define the gaps and fill these with open > standards, building on the fundaments of ISO and others. In the cards > world, you could say that EMV dit that as well, athough still not as open > as is the case with W3C... > > +1 - although we shouldn't expect the world to simply patch the holes and > ignore the opportunities to embrace the Web as a replacement for these > legacy networks that run on ISO-developed protocols. > > At the end of the day the ISO protocols can easily be adapted to run on > the Internet as opposed to private networks and I expect that this will > ultimately be the way things move (unless the ISO protocols prove to be a > hindrance to this or some other factor impacts this). > > I see our role within the IG as being the facilitators of a process where > everybody wins. Ideally the traditional institutions like FIs, SWIFT, ISO > embrace the Internet as the infrastructure upon which they will build their > next iteration of payments services and will use mature and trusted Web > technologies to do it. In that way the innovation on that system is not > limited to large organisations with specialized knowledge of the domain. > > The incumbents benefit from an ecosystem that is able to innovate and > evolve much faster than before and developers are empowered to participate > in this process (even if it's just a guy with his laptop and an internet > connection). > > > > > > Comments welcome! > > > > Evert Fekkes > > Rabobank > > > > *Van:* Adrian Hope-Bailie [mailto:adrian@ripple.com] > *Verzonden:* woensdag 2 september 2015 15:32 > *Aan:* KETELS Kris > *CC:* Adrian Hope-Bailie; Kepeng Li; Adler, Patrick; Fekkes, ER (Evert); > VIGNET cyril; j.j.spaanderman@dnb.nl; Web Payments IG; Ian Jacobs > *Onderwerp:* Re: Organize a chat on account/ledger capabilities? > > > > Hi Kris, > > > > I'd classify ISO 20022 as an exception. The development of the standard > was done in the traditional ISO manner but the standard is just a > methodology that laid a foundation for open development of the messaging > standards. > > > > Traditionally ISO standards are developed quite differently to Web > standards. They are developed in closed groups under strict confidentiality > and the standards themselves are not free and open for anyone to download > and implement royalty-free. > > > > The W3C (like the IEEE, ETT Internet Society etc ) are advocates of open > standards principals: https://open-stand.org/ which are quite different > to the principals of ISO. > > > > That is not to say there are not reasons for there to be different > approaches to standardisation for different circumstances but from the > perspective of Web technology development I would strongly favour open > standards. > > > > Some illustrative anecdotes: > > > > I worked for a long time at for a very large payments software vendor > where we spent a lot of our time ensuring our software was compliant with > the latest specifications. These were usually variations of ISO8583 from > different networks. All of these specs were closely guarded confidential > documents that required careful management of their distribution. To this > day I have not seen a copy of the original ISO8583 spec from ISO because my > company would have had to pay a lot of money for it just for me to have > that privilege. > > > > I am part of the W3C liaison with ISO for ISO12812 and have had to install > a whole load of document lifecycle management software on my laptop just to > be able to receive documents to do my work. > > > > The reality is that the ISO model may work in manufacturing or similar > industries where there are layers of abstraction from the specification to > the implementation and the cost of getting your hands on the spec is > minimal in comparison to all of the other input costs. > > > > On the Web, where some products are developed with almost zero overheads > on tiny budgets as they attempt to get traction this model simply doesn't > work. The only people that can afford to be bothered with ISO specs are > already large companies the majority of whom are struggling to innovate > fast enough to defend themselves against the threat of the small start-ups > (especially so in the financial technology sector). > > > > So, I can imagine these incumbents being very supportive of ISO > specifications, especially in jurisdictions where they have implicit > regulatory backing, but that would simply be because it helps them maintain > their defense against disruptive innovators that see proprietary and closed > specifications as barriers to entry. > > > > On ISO20022 specifically: > > > > I think the approach taken with ISO20022 is excellent. I am certain it > will become the language of payments globally and that is attributable in > large parts to the availability of information on it's use. It's the only > developer friendly ISO specification initiative I am aware of. > > > > I would like it if JSON encoding was supported as a first-class citizen > since that is the the most common data encoding format on the Web (I know > it's possible just not easy). > > > > I would also be interested to know if ISO20022 had picked a linked-data > format (like JSON-LD) for encoding if the current plethora of message types > and fields and complexity could have been avoided but who can say. > > > > On Wed, Sep 2, 2015 at 1:40 PM, KETELS Kris <Kris.KETELS@swift.com> wrote: > > Hi Adrian, > > > > Can you explain why you qualify ISO standards as being the opposite of > open W3C standards? > > I myself haven’t encountered a more open (financial) standard as ISO 20022. > > > > > > Kind regards > > Kris > > > > > > *From:* Adrian Hope-Bailie [mailto:adrian@hopebailie.com] > *Sent:* 19 August 2015 18:58 > *To:* Ian Jacobs > *Cc:* Kepeng Li; Adler, Patrick; Adrian Hope-Bailie; Evert Fekkes; VIGNET > cyril; j.j.spaanderman@dnb.nl; Web Payments IG > *Subject:* Re: Organize a chat on account/ledger capabilities? > > > > Hi Ian, > > Definitely interested. It would be great if the standards that were used > for XS2A came out of this group and followed all of the open standards > principles of the W3C and used Web technology as opposed to some ISO > standard. > > We need to get some direct participation from the EPC, EBA etc > > Adrian > > > > On 19 August 2015 at 18:45, Ian Jacobs <ij@w3.org> wrote: > > Hi Kepeng, Pat, Adrian, Evert, Cyril, Jurgen, (and others who may be > interested), > > I was chatting with Kepeng yesterday about capabilities related to > account/ledger access. We were discussing > the sorts of useful things one could do if there were standard APIs for > account/ledger access, including building > risk monitoring systems that would have an easier time working with > diverse types of accounts. Also, I wondered > whether PSD2 regulation in Europe might be leading to a need for open > standards to provide access to > accounts from Web applications. > > Maybe we can organize a Thursday call around this topic so that we can > determine who is interested, and > whether, for example, there is even enough interest to start a task force. > > Please let me know if this discussion would interest you. Thanks! > > Ian > > -- > Ian Jacobs <ij@w3.org> http://www.w3.org/People/Jacobs > Tel: +1 718 260 9447 > > > > > > ====================================================== > Rabobank disclaimer: http://www.rabobank.nl/disclaimer > > >
Received on Thursday, 3 September 2015 16:05:42 UTC