RE: Paper on Summary of ISO12812 by Alan Thiemann

Hello again:
I’m confused by Anders response.  Let me attempt clarify what my comment meant.

Nick Telford-Reed wrote:
> That pretty much at a stroke knocks out Host Card Emulation, which is Google's approach to mobile payments, 
> so I think I would be reluctant to make that step.

My comment intended - if there is something here that is bad from our point of view, we can raise a comment.  Full stop.

I don't know what relevance our current provisioning design ideas (or lack of them) have.

Best regards,
David

From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com] 
Sent: Thursday, May 21, 2015 9:06 AM
To: David Ezell
Cc: Web Payments IG; Adrian Hope-Bailie; Joerg.Heuer@telekom.de; ajthiemann@gmail.com; ??(??); Telford-Reed, Nick
Subject: RE: Paper on Summary of ISO12812 by Alan Thiemann


On May 21, 2015 2:53 PM, "David Ezell" <David_E3@verifone.com> wrote:
>
> Hello all:
>
>  
>
> Nick wrote:
>
> >if we restrict the development of payment solutions to architectures that require a complex ecosystem of security providers as well as the
>
> >solution provider itself, we bake in a set of complexities that have held back mobile payments for years.
>
>  
>
> I do agree with Nick.  If indeed
> ISO12812 prevents HCE, we should be
> prepared take the sentiment above
> back to them in the form of a comment. 
Nick didn't say that.
What's powering a "mechanism" like HCE is a part of a key provisioning process, a work-item which WPIG have yet to address.
Anders
Currently (or soon to be currently) Adrian and I will be the “experts”[1] who can do that.  In order to express this kind of opinion, we will need some form of consensus, since we represent the IG, not ourselves.
>
>  
>
> Best regards,
>
> David
>
>  
>
> [1] https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Apr/0169.html

>
>  
>
> From: Telford-Reed, Nick [mailto:Nick.Telford-Reed@worldpay.com] 
> Sent: Thursday, May 21, 2015 8:32 AM
> To: 'Adrian Hope-Bailie'
> Cc: ??(??); Joerg.Heuer@telekom.de; public-webpayments-ig@w3.org; ajthiemann@gmail.com; David Ezell
> Subject: RE: Paper on Summary of ISO12812 by Alan Thiemann
>
>  
>
> I think it _can_ be stored there but it doesn’t _need_ to be. The point of HCE is that it allows some (perhaps limited) set of credentials to be held in application space on the device so that a payment application developer can create payment applications without needing a commercial and technical relationship with a third-party that holds the keys/controls for a dedicated hardened secure area.
>
>  
>
> IMO if we restrict the development of payment solutions to architectures that require a complex ecosystem of security providers as well as the solution provider itself, we bake in a set of complexities that have held back mobile payments for years.
>
>  
>
> There are other ways to manage the risk with things like limited use (by time, channel, device, amount) tokens so that cost of compromise is reduced be implementations remain straightforward.
>
>  
>
> Your point is well made that in HCE much of the secret sauce is kept off the device – but there is still sensitive material in user space (or at least, there can be).
>
>  
>
> Nick
>
> --
>
> Nick Telford-Reed
>
> e: nick.telford-reed@worldpay.com | m: +447799473854 | t: +44 203 664 5069
>
>  
>
> From: Adrian Hope-Bailie [mailto:adrian@hopebailie.com] 
> Sent: 20 May 2015 15:12
> To: Telford-Reed, Nick
> Cc: ??(??); Joerg.Heuer@telekom.de; public-webpayments-ig@w3.org; ajthiemann@gmail.com; David_E3@VERIFONE.com
> Subject: Re: Paper on Summary of ISO12812 by Alan Thiemann
>
>  
>
> I think you can accommodate HCE by saying that this kind of data should be stored in the SE or TEE etc IF it is stored on the device?
>
>  
>
> On 20 May 2015 at 11:28, Telford-Reed, Nick <Nick.Telford-Reed@worldpay.com> wrote:
>
> That pretty much at a stroke knocks out Host Card Emulation, which is Google's approach to mobile payments, so I think I would be reluctant to make that step.
>
>
>
> --
> Nick Telford-Reed
> e: nick.telford-reed@worldpay.com | m: +447799473854 | t: +44 203 664 5069
>
> > -----Original Message-----
> > From: 孙倩(雪迪) [mailto:sunqian.sq@alibaba-inc.com]
>
> > Sent: 19 May 2015 04:10
> > To: Joerg.Heuer@telekom.de; public-webpayments-ig@w3.org
> > Cc: ajthiemann@gmail.com; David_E3@VERIFONE.com
> > Subject: 答复: Paper on Summary of ISO12812 by Alan Thiemann
> >
> > Hi all,
> > So, can we change the description to "Important data, such as the fingerprint
> > template and private key, and sensitive code should be stored and executed
> > in a security area (e.g. TEE, SE etc.) "?
> >
> >
> >
> >
> > -----邮件原件-----
> > 发件人
> : Joerg.Heuer@telekom.de [mailto:Joerg.Heuer@telekom.de]
> > 发时间: 2015年5月18日 22:58
> > 收件人: 孙倩(雪迪); public-webpayments-ig@w3.org
> > 抄送: ajthiemann@gmail.com; David_E3@VERIFONE.com
> > 主题: RE: Paper on Summary of ISO12812 by Alan Thiemann
>
> >
> > Hello,
> >
> > While we definitely support the importance of security hardware for the use
> > of privacy-risky technology, I suppose to not explicitly ask for a technology,
> > but rather talk about its capabilities. For several uses an SE might still be okay,
> > though TEE might be desirable for the future. In fact, it might take a long time
> > for TEEs to proliferate until then, we should allow existing solutions to kick in
> > as soon as possible. I'd probably try to even think about how TPM/ MTM
> > could be helpful too.
> >
> > In this case, I'd propose to just refer to a "technology to store and validate
> > fingerprint templates in separate security hardware on the device or
> > physically connected to it".
> >
> > Cheers,
> >       Jörg
> >
> > -----Original Message-----
> > From:
> 孙倩(雪迪) [mailto:sunqian.sq@alibaba-inc.com]
>
> > Sent: Montag, 18. Mai 2015 09:10
> > To: 'David Ezell'; public-webpayments-ig@w3.org
> > Cc: 'Alan J. Thiemann'
> > Subject:
> 答复: Paper on Summary of ISO12812 by Alan Thiemann
>
> >
> > Thanks for Alan's summary.
> >
> > For the" Part 2: Security and data protection for mobile financial
> > services"
> ，I have some consideration that in order to protect financial
>
> > privacy useful, the mobile device technology should combines Secure
> > Elements
> > (SE) and a Trusted Execution Environment (TEE) to protect payment
> > credentials. Beacause the SE only has Limited processing and storage
> > capacity, but TEE can offer safe execution of authorized security software,
> > known as 'trusted applications', enables it to provide end-to-end security by
> > enforcing protection, confidentiality, integrity and data access rights.
> >
> > And when we design the payment architecure and use cases, we should also
> > pay attention to that some payment application should be served as a
> > TA(trusted
> > appliation) to run in the TEE for security.
> >
> > For example in the Use case  "6.2.3.1 Non-essential Use Cases -Biometric",
> > we have already emphasized as following:
> > An individual's privacy should be protected when performing any sort of
> > biometric authentication.
> > Important data, such as the fingerprint template and private key, and
> > sensitive code should be stored and executed in a Trusted Execution
> > Environment (TEE).
> >
> > -----
> 邮件原件-----
> > 发件人: David Ezell [mailto:David_E3@VERIFONE.com]
> > 发送时间: 2015年5月18日 0:56
> > 收件人: public-webpayments-ig@w3.org
> > 抄送: Alan J. Thiemann (ajthiemann@gmail.com)
> > 主题: Paper on Summary of ISO12812 by Alan Thiemann
>
> >
> > Dear Web Payments group:
> >
> > My colleague Alan Thiemann[1] has written a summary of ISO 12812[2].  This
> > work is Alan's opinion of the work - not official.  But it is a very good
> > introduction to the work and the expected trajectory at ISO.
> >
> > I would request that everyone in our group give this paper consideration - it
> > won't take long, and will help inform any needed discussion.
> >
> > Best regards,
> > David
> >
> > [1] Alan is on the Board of Advisors for Conexxus (NACS technology) and
> > does work for NACS.  He serves as chair of the X9 Mirror Group handling ISO
> > 12812 work in the US.
> > [2]
> > https://lists.w3.org/Archives/Member/w3c-archive/2015May/att-

> > 0254/Executive_
> > Summary_of_ISO_12812_05012015.pdf
> > ________________________________
> > This electronic message, including attachments, is intended only for the use
> > of the individual or company named above or to which it is addressed. The
> > information contained in this message shall be considered confidential and
> > proprietary, and may include confidential work product. If you are not the
> > intended recipient, please be aware that any unauthorized use,
> > dissemination, distribution or copying of this message is strictly prohibited. If
> > you have received this email in error, please notify the sender by replying to
> > this message and deleting this email immediately.
> >
> >
> >
>
> This e-mail and any attachments are confidential, intended only for the addressee and may be privileged. If you have received this e-mail in error, please notify the sender immediately and delete it. Any content that does not relate to the business of Worldpay is personal to the sender and not authorised or endorsed by Worldpay. Worldpay does not accept responsibility for viruses or any loss or damage arising from transmission or access.
>
> Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct Authority No: 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct Authority No: 502597). Registered Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam, the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted through www.dnb.nl. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.
>
>  
>
>  
>
>  
>
> This e-mail and any attachments are confidential, intended only for the addressee and may be privileged. If you have received this e-mail in error, please notify the sender immediately and delete it. Any content that does not relate to the business of Worldpay is personal to the sender and not authorised or endorsed by Worldpay. Worldpay does not accept responsibility for viruses or any loss or damage arising from transmission or access.
>
>  
>
> Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct Authority No: 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct Authority No: 502597). Registered Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam, the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted through www.dnb.nl. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.
>
>  
>
>  
>
> ________________________________
> This electronic message, including attachments, is intended only for the use of the individual or company named above or to which it is addressed. The information contained in this message shall be considered confidential and proprietary, and may include confidential work product. If you are not the intended recipient, please be aware that any unauthorized use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and deleting this email immediately.

Received on Thursday, 21 May 2015 13:41:48 UTC