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

John Bradley ve7jtb at ve7jtb.com
Sat Jun 4 11:37:14 UTC 2016


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/017984e1/attachment-0001.html>


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