[Openid-specs-mobile-profile] MODRNA WG Call June 1st 2016

torsten at lodderstedt.net torsten at lodderstedt.net
Sat Jun 4 11:57:38 UTC 2016


So the logic is supposed to be:
1) lookup ppid
2) compare associated iss
3) if iss differs from value of issues claim in the id token - invoke old issuser's introspection endpoint 

That also implies the RP cannot distinguish porting from account take over without the help of the old issuer. Right?

That's a lot of Mobile Connect _specific_ logic. I would really appreciate a general OIDC solution. That's easier for lmplementers, both RP and OP.

I also don't see the simplification. The logic for processing the migration JWT is quite the same as for an ordinary id token.

Shall we sketch out a draft?


-------- Originalnachricht --------
Betreff: Re: [Openid-specs-mobile-profile] MODRNA WG Call June 1st 2016
Von: John Bradley <ve7jtb at ve7jtb.com>
An: Torsten Lodderstedt <torsten at lodderstedt.net>
Cc: Torsten.Lodderstedt at telekom.de,openid-specs-mobile-profile at lists.openid.net,philippe.clement.ft at gmail.com,John Bradley <jbradley at mac.com>

>I am not arguing for a introspection endpoint.
>
>It would allow the client to do less crypto and have the mno validate the
>signature.   That might also help avoid any problem caused by key
>rotation.  ( I pointed out that since you can have multiple keys in the
>JWKS that rotation is not a real problem).
>
>If subjects are not stable, the client would need to look in the token to
>find the old mno to use there introspection endpoint(or you could add extra
>paramaters).
>
>If sub are stable( what the GSMA proposal was) then the client would not
>need anything in the JWT (no porting token if I understood) they would look
>at the old issue in the user record and introspect the subject with them.
>
>The downside of that is that the donating IdP needs to keep all the records
>to provide the service.
>
>If you can't to put the burden on the old IdP and allow sub to change then
>you could send the old sub and issuer in the id_token unsigned.   The
>client would then send the sub to the old issuer to get the new issuer from
>the introspection endpoint.   That is essentially the openid 2 flow.   By
>using the signed jwt we eliminate the need for the doner to keep all the
>old records and run a service.
>
>In the general case the doner might go out of business etc so making the
>IdP porting in responsible is probably safer.
>
>John B.
>On Jun 4, 2016 3:52 AM, "Torsten Lodderstedt" <torsten at lodderstedt.net>
>wrote:
>
>Hi John,
>
>what is the benefit of having such an introspection endpoint over providing
>all necessary data in a login response extension?
>
>How is the RP supposed to determine a ported user account?
>
>kind regards,
>Torsten.
>
>Am 03.06.2016 um 17:16 schrieb John Bradley <ve7jtb at ve7jtb.com>:
>
>I did make those points.
>
>For a Connect migration process we cannot assume that the sub value (pcr
>format in the GSMA case) will stay the same.  In most cases it needs to
>change.
>
>I am fine with the GSMA mandating that it stay the same between MNO but
>that would be a special case and RP should not depend on it or bad things
>will happen down the road.
>
>I think that is harder for the MNO and has no real benefit.
>
>I believe some people at the GSMA want it to stay the same because
>currently they think that some/ all mobile connect RP are ignoring the
>issuer.
>That really needs to be corrected is should be a separate issue.
>
>The one downside of keeping it the same is that it may encourage people to
>make bad assumptions about the importance of issuer.
>The nuge nuge wink wink yes issuer is required but if you are using mobile
>connect the sub values are unique and you could just use it as a primary
>key for your users.
>
>That could be dpangerious long term and cause serious security issues for
>RP if they were to treat all open ID connect providers that way.
>
>My main concern at this point is that the migration spec allow for the sub
>value to change even if the MNO don’t by policy.
>
>The issue if the signing keys is not a big one.
>
>The MNO publishes a JWKS that can contain multiple keys, and each key has
>its own keyid.
>The MNO doesn’t need to use the same signing key that is used for JWT if
>that is on a fast rotation.
>Having two porting signing keys in the JWKS and rotating once a year is
>probably food enough.  You could leave a two year window if required.
>These are RSA keys most likely and it used to be that rotating them every
>five years was good enough,  so using the same key for a year for the
>porting info should not be a big deal.
>
>You could have a introspection endpoint and pass the signed JWT for the MNO
>to validate if you want.
>
>The idea put forward by the GSMA of keeping the PCR stable and having the
>RP use the old PCR to query a MNO endpoint to get the porting information
>requires the MNO to keep the old info for longer.   It requires the
>identifier to be stable so would not work for a general connect spec.  I
>appreciate that it is simple for the RP, but I think it rises too many
>risks.
>
>John B.
>
>
>On Jun 3, 2016, at 7:51 AM, Torsten.Lodderstedt at telekom.de wrote:
>
>HI all,
>
>did you discuss scoping of sub/PCR values by the issuer value? Will the
>respective GSMA spec be changed or are Mobile Connect RP/SPs still supposed
>to recognize an user account based on the sub claim only?
>
>My hypothesis: if the migration process is implemented properly and uses
>scoped user ids, then the value of a PCR, which is stable across MNOs, is
>rather small. The RP just saves the database update in case of the
>migration process.
>
>kind regards,
>Torsten.
>
>*Von:* philippe.clement at orange.com [mailto:philippe.clement at orange.com
><philippe.clement at orange.com>]
>*Gesendet:* Freitag, 3. Juni 2016 11:04
>*An:* Lodderstedt, Torsten; openid-specs-mobile-profile at lists.openid.net;
>John Bradley
>*Cc:* philippe.clement.ft at gmail.com; philippe.clement.ft at gmail.com
>*Betreff:* RE: MODRNA WG Call June 1st 2016
>
>Dear all,
>
>Please consider below a new version of the minutes of our call, following
>some suggestions from Siva, and contribute if you feel you have to.
>Updates in *italics*
>
>
>*Participants*: John, Bjorn, Nat, Philippe, Siva, Jörg
> *Agenda* : Progress on GSMA PCR portability, Change to MC Authorisaiton
>minutes
>·         Some discussions happened in CPAS about signing JWT and chain
>migration from a user to different MNOs
>·         John explains that signing JWT is wishable and not complex for an
>MNO
>·         An introspection endpoint is needed on MNO side to attest the
>signed JWT to the RP. Keys rotating will be taken into account. Special
>keys for the Use Case ?
>·         Discussion about the PCR and the fact it must be stable in time
>or different from an MNO to another regarding the same user at the same RP.
>The generality of the migration process is wishable, so addressing
>different PCR for the same user at an RP for different MNO is acceptable.
>On the other hand, the MNO process to create PCR is not standardized yet,
>and no vision is available on the delay for all MNO to change their PCR
>method.
>·         *Siva informed forum members that CPAS members agreed the PCR new
>format (GUID, version 4, RFC 4112) and all MNOs will migrate to generate in
>this format, ( few MNOs are already working on this migration). PCR new
>format and migration is being executed as a separate deployment project for
>the moment. (De-coupled from current Mobile Connect release).*
>·         Discussions about the period while to maintain the migration open
>for a user at an MNO.
>·         *John explains that if we keep the same PCR for migration, then
>it will be Mobile Connect specific migration, and it cannot be made as a
>generic solution from OpenID Connect specifications.  (Perhaps specs can
>come with multiple options/choice).*
>·         Chain migration: discussions on the management of the signed JWT
>and which MNOs the JWTs will be addressed to. Proposal: sent each signed
>JWT to respective MNOs.
>·         *Siva informed forum members of changing the wording in the
>minutes regarding MC Authorisation since it is creating much confusion for
>R2 activities.  Also informed that MC Authorisation is just a marketing
>term w.r.t. Mobile Connect, whereas it is “Contextual Authentication” with
>additional features, which is well aligned with OIDC protocol and fit for
>purpose in R2.   Joerg informed that there would not be a problem to change
>the minutes.*
>·         *If agreed/required all Mobile Connect improvements/discussions
>apply to Mobile Connect future releases only.*
>·         Discussions in CPAS to be led by Siva
>
>Best regards,
>Philippe
>
>_____________________________________________
>*De :* CLEMENT Philippe IMT TECHNO
>*Envoyé :* jeudi 2 juin 2016 09:41
>*À :* Torsten.Lodderstedt at telekom.de;
>openid-specs-mobile-profile at lists.openid.net; John Bradley
>*Cc :* philippe.clement.ft at gmail.com
>*Objet** :* MODRNA WG Call June 1st 2016
>
>
>Dear all,
>
>Please find below the preliminary notes of the meeting
>Any error or adjustment needed, please let me know
>
>*Participants*: John, Bjorn, Nat, Philippe, Siva, Jörg
>
>*Agenda* : Progress on GSMA PCR portability
>
>Some discussions happened in CPAS about signing JWT and chain migration
>from a user to different MNOs
>John explains that signing JWT is wishable and not complex for an MNO
>An introspection endpoint is needed on MNO side to attest the signed JWT to
>the RP. Keys rotating will be taken into account. Special keys for the Use
>Case ?
>
>Discussion about the PCR and the fact it must be stable in time or
>different from an MNO to another regrding the same user at the same RP. The
>genericity of the migration process is wishable, so addressing different
>PCR for the same user at an RP for different MNO is acceptable. On the
>other hand, the MNO process to create PCR is not standardized yet, and no
>vision is available on the delay for all MNO to change their PCR method.
>Discussions about the period while to maintain the migration open for a
>user at an MNO.
>Chain migration: discussions on the management of the signed JWT and which
>MNOs the JWTs will be addressed to. Proposal: sent each signed JWT to
>respective MNOs.
>
>·         Discussions in CPAS to be led by Siva
>
>Kind regards,
>Philippe
>
>-----Rendez-vous d'origine-----
>*De :* Torsten.Lodderstedt at telekom.de [mailto:Torsten.Lodderstedt at telekom.de
><Torsten.Lodderstedt at telekom.de>]
>*Envoyé :* lundi 30 mai 2016 13:55
>*À :* Torsten.Lodderstedt at telekom.de;
>openid-specs-mobile-profile at lists.openid.net
>*Objet :* [Openid-specs-mobile-profile] MODRNA WG Call
>*Date :* mercredi 1 juin 2016 16:00-17:00 (UTC+01:00) Amsterdam, Berlin,
>Berne, Rome, Stockholm, Vienne.
>*Où :* https://global.gotomeeting.com/join/927253461
>
>
>
>
>Zeit: Mittwoch, 1. Juni 2016 16:00-17:00 (UTC+01:00) Amsterdam, Berlin,
>Bern, Rom, Stockholm, Wien.
>Ort: https://global.gotomeeting.com/join/927253461
>
>Hinweis: Die oben angegebene Abweichung von GMT berücksichtigt keine
>Anpassungen für Sommerzeit.
>
>*~*~*~*~*~*~*~*~*~*
>
>Hi all,
>
>the objective of this call is to discuss the tasks we came up with during
>the technical workshop. Please take a look onto the respective issues in
>our tracker in advance:
>https://bitbucket.org/openid/mobile/issues?milestone=TWS_DA_05_2016
>
>
>best regards,
>Torsten.
>  << Fichier: ATT00001.txt >>
>
>
>_________________________________________________________________________________________________________________________
>
>
>
>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.
>
>_______________________________________________
>Openid-specs-mobile-profile mailing list
>Openid-specs-mobile-profile at lists.openid.net
>http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>
>
>_______________________________________________
>Openid-specs-mobile-profile mailing list
>Openid-specs-mobile-profile at lists.openid.net
>http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160604/7616c307/attachment-0001.html>


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