[Openid-specs-mobile-profile] [E] Re: [Openid-specs-fapi] FYI: OpenID Implementer’s Drafts of Four MODRNA Specifications Approved

[Tom Jones]

I object to the lack of user control on the questioning process itself.
The spec must explicitly describe the manner that the user can control the
questioning process.
If not I believe that it too intrusive on the user's time and attention.
This spec will be misused if there is not some control on it.
..tom

On Tue, May 16, 2017 at 12:59 AM, <nicolas.aillery at orange.com> wrote:

> Hello Tom,
>
>
>
>    The User Questioning API is specified as an Oauth 2-protecterd Resource
> Server, i.e. consuming an Access Token.
>
>    The way the user consent is retrieved (or not) depends on the
> Authorization Server policy when delivering the Access Token to the Client.
>
>    Note that the Access Token can be tied with a user or not. When the
> Access Token is tied with a user, we agree that’s very important to get a
> user consent first.
>
>
>
>    The User Questioning API enables a Client to question an End-User.
>
>    Note, it’s not an API to get a user’s consent for the AS, it’s an API
> to get a user’s answer for the Client (i.e. the question and answer are
> meaningless for the AS).
>
>
>
>    The interaction with the End-User is the business of the UQ API.
>
>    As the UQ API is designed in MODRNA for GSMA needs, we envision a
> mobile communication exchange, but this specification can be used in other
> contexts.
>
>
>
> Regards,
>
>
>
> Nicolas
>
>
>
>
>
> *De :* Openid-specs-mobile-profile [mailto:openid-specs-mobile-
> profile-bounces at lists.openid.net] *De la part de* Tom Jones
> *Envoyé :* mardi 16 mai 2017 00:03
> *À :* Hjelm, Bjorn
> *Cc :* openid-specs-mobile-profile at lists.openid.net; Nat Sakimura
> *Objet :* Re: [Openid-specs-mobile-profile] [E] Re: [Openid-specs-fapi]
> FYI: OpenID Implementer’s Drafts of Four MODRNA Specifications Approved
>
>
>
> As indicated in the comment, it is the Questioning spec.
>
>
>
> Am I correct in assuming the spec applies to the telco's app in the users'
> phones?
>
>
>
> thx  ..tom
>
>
>
> On Mon, May 15, 2017 at 12:55 PM, Hjelm, Bjorn <
> Bjorn.Hjelm at verizonwireless.com> wrote:
>
> Tom,
>
> Thanks for taking the time to review the draft(s). First, John should be
> able to help set you up to get access to bitbucket to allow you to submit
> items for the issue tracker.
>
>
>
> Second, are your comments against Client Initiated Backchannel
> Authentication, User Questioning API, both, or another of the four
> specifications that were approved as Implementer’s Draft?
>
>
>
> BR,
>
> Bjorn
>
>
>
> *From:* Tom Jones [mailto:thomasclinganjones at gmail.com]
> *Sent:* Monday, May 15, 2017 12:16 PM
> *To:* Hjelm, Bjorn; Nat Sakimura
> *Subject:* Re: [E] Re: [Openid-specs-fapi] FYI: OpenID Implementer’s
> Drafts of Four MODRNA Specifications Approved
>
>
>
> I finally got time to review one of the documents, questioning, and went
> to the bitbucket site, only to find access denied.
>
>
>
> My first problem was how to understand the spec at all with no overall
> architecture or threat model data flow diagram.
>
> I take it that the doc is oriented to a phone company client residing on a
> user's smart phone?
>
> I have some real problems with this from the user perspective.
>
> The spec addresses privacy as tho it was only the user private information
> that was under attack.
>
> The reality is that user attention is also precious and needs to be under
> user control.
>
> This spec does not address the acquisition of user consent to receive any
> of the messages, or to control which one can be supplied.
>
> That would required a set of (claims?) that the user can consent to
> receive.
>
>
>
> Nat, the same comments would apply to notices from any FI. I consent to
> receive some SMS from my various FIs and am given a good measure of control
> about which and how often.
>
> We need that as well as inclusion of user attention in any privacy
> statement.
>
> ..tom
>
>
>
> On Fri, May 12, 2017 at 10:00 AM, Hjelm, Bjorn <
> Bjorn.Hjelm at verizonwireless.com> wrote:
>
> Tom,
>
> We would appreciate any input on any of the four specifications. Please
> post the comments to the MODRNA Issue Tracker (
> https://bitbucket.org/openid/mobile/issues
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_openid_mobile_issues&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=NMZJHCV8pjvGIH2fTx9z6l7g7-V-a2xW7ISf9uHdz0A&m=atBJ-6H_z962nk3eN3GXHnp6TESqTje2b8L7syzH1vk&s=e30N3cb-5spp8lgcYCjT5q7ormFIlDDY0UnqdfGnq2o&e=>).
>
>
>
>
> BR,
>
> Bjorn
>
>
>
> *From:* Openid-specs-fapi [mailto:openid-specs-fapi-
> bounces at lists.openid.net] *On Behalf Of *Tom Jones via Openid-specs-fapi
> *Sent:* Wednesday, May 10, 2017 8:49 AM
> *To:* Nat Sakimura; Financial API Working Group List
> *Subject:* [E] Re: [Openid-specs-fapi] FYI: OpenID Implementer’s Drafts
> of Four MODRNA Specifications Approved
>
>
>
> Yes.  Especially man-in-browser.
>
>
>
> But as the sole objector to those specs i would like to avoid exchanging
> any personal data between FIs.
>
> It was the spec that exchanged personal data between phone companies that
> i found objectionable.
>
> I would wish that any future vote not lump multiple specs into one ballot.
>
> ..tom
>
>
>
> On Wed, May 10, 2017 at 2:45 AM, Nat Sakimura via Openid-specs-fapi <
> openid-specs-fapi at lists.openid.net> wrote:
>
> Now that they are Implementer's draft and the IPR is locked in, we can
> safely refer to them. User questioning and Backchannel login are really
> interesting for us. They can mitigate the risk of man-in-the-browser. It
> has been a bit unfortunate timing-wise, but we should consider adding one
> of them at least in the next revision. Is there an appetite to bite them?
>
> --
> Nat Sakimura
> Research Fellow, Nomura Research Institute
> Chairman of the Board, OpenID Foundation
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dfapi&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=NMZJHCV8pjvGIH2fTx9z6l7g7-V-a2xW7ISf9uHdz0A&m=wYjcjsNl4eIFgF69gUKY1fjOgq4nx4CDV2X40SKxMY8&s=g9kTYOxXzBnV_HQiBh1KG-CtkGJJcFQCod7Hk5LioMo&e=>
>
>
>
>
>
> --
>
> ..tom
>
>
>
>
> --
>
> ..tom
>
>
>
>
> --
>
> ..tom
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>


-- 
..tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170522/8a5fafc0/attachment-0001.html>