[Openid-specs-mobile-profile] MODRNA WG Call on Jan 9th 2018 final minutes

philippe.clement at orange.com philippe.clement at orange.com
Thu Jan 11 12:32:14 UTC 2018

Dear all,
Please find below the final notes of our call on Jan 9th 2018. Thank you all for the comments.

Roll Call
Adoption of the Agenda [Bjorn/John]
Liaisons Updates
GSMA [Siva]
Working Group Updates
Issue Tracker
Authentication profile

Roll Call
Bjorn (Verizon)
John (Yubico)
Gonzalo (Telefonica)
Hubert, Philippe (Orange)
Jörg (DT)
Marianne Grima (Deloitte & Touche LLP)
Petteri (Ubisecure)

Guest: Adam Brake

Adoption of the Agenda [Bjorn/John]
Agreed, no addition.

Liaisons Updates
GSMA [Siva]
Siva not on the call.
Hubert mentions Orange, Telefonica and Telstra paper for usage of UQ API at Mobile Connect Commercial & Products Forum.
UQ API specification introduced to FAPI WG at Dec. 20 call per request with some brief follow-up discussions with Dave T by e-mail before end of year.
*       Bjorn will raise the question of next steps to Nat on the upcoming FAPI WG call on Jan. 9<https://bitbucket.org/openid/fapi/wiki/FAPI_Meeting_Notes_2018-01-09>

Working Group Updates

OpenID Foundation & Open Banking Workshop Hosted by OIX in London on Jan. 30<http://oixuk.org/events/oix-workshop-openid-open-banking-oix-3/>.

Issue Tracker

Authentication Profile (Jörg)
*       #33: modrna - claim: I would vote to not put this into the basic authentication spec. In my opinion the topic here is about authorization of a transaction not about authenticating a user.

*       #22: is actually about the same thing. So I would vote to merge #32 and #22 an consider an additional document to handle those transactional authorizations.
*       #38: amr values. Those are not really specific to mobile connect so they should be addressed in RFC 8176.
*       Changing an RFC is not possible, but adding a doc is, maybe external.
*       --> To collect possible amr first
*       #39: error handling: We really should reserve some time to discuss this during a WG call
*       Some people think the RP has to check if the returned info are acceptable and that it should be up to the RP to decide according the returned info. Other ones think that error handling has a benefit.
*       A case is discussed regarding the request of a certain acr by the RP.
* of the OIDC spec specifies how to deal with requested acr claim from the RP, should it be essential or requested by acr_values for the id_token.
--> Discussion to be continued on the next call and mailing list.
*       #40: loa4 handling: We could take the approach from the current mobile connect profile here. (And pull it down to the MODRNA spec)
*       No possible implementation of mobile connect to make that. Try to be more specific on what is behind LOA4.
*       Wait for IGov WG conclusions, according to a LOA4 profile. IGov document covering highest level assurance.
*       --> Keep it open for now
*       #42: pcr as login hint: I would vote to close this issue. In the next version Mobile Connect Profile will support MODRNA login_hint_token.
*       Pcr, a concept of MC (personal customer reference). No more needed since MC supports the LHT.
*       --> To be closed
*       #43: phishing: I am really no expert on phishing. John should take a look at it.
*       Session highjacking is more appropriate.
*       --> Issue assigned to John for comment
*       #61: OpenAPI respresentation: Still waiting for Nat's reply here.
*       --> Bjorn to ping Nat on this.
For the next call
Other - None
AOB - None

Best regards,


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20180111/96a43c71/attachment.html>

More information about the Openid-specs-mobile-profile mailing list