[Openid-specs-mobile-profile] New Version of Account Migration Draft

Torsten.Lodderstedt at telekom.de Torsten.Lodderstedt at telekom.de
Thu Aug 4 08:33:33 UTC 2016


Hi Arne,

thanks for your please feedback. Please find my comments inline.

best regards,
Torsten.

Von: Arne Georg Gleditsch [mailto:argggh at telenordigital.com]
Gesendet: Dienstag, 2. August 2016 15:39
An: Lodderstedt, Torsten
Cc: openid-specs-mobile-profile at lists.openid.net
Betreff: Re: [Openid-specs-mobile-profile] New Version of Account Migration Draft

Hi all,

Thanks for a great job on the draft, Torsten.
Thanks J
I have some further suggestions:
1) The draft explicitly states that chained migration is out of scope.  However, as far as I read the current draft, if we just allow the from clause of a migration_data claim to itself contain a nested migration_data claim, we would have it for free.
I personally do not believe anything in life comes for free ;-) My intention is to keep the complexity of this draft on a reasonable level. And I do not see the need for chained migration (yet).
Having said that, I’m open for your proposal. Please propose text, we could add to the draft describing the formats and processing rules for nested migration data. I think we also need to keep an eye on potential additional security threats. Such a proposal would serve as a base for detailed discussion in the WG.

2) We are inflating the size of the id_token a bit.  What if we instead of (or as an alternative to) the migration_data claim had a migration_data_url claim, indicating an endpoint that could be accessed to obtain the actual migration data payload?  (This endpoint should be accessed with authorization bearer carrying the user's access token.)
Interesting idea – But I’m worried about the fact the old OP would need to maintain a database of _all_ issued migration JWTs (the respective data and id to be more precisely). Moreover, login to the RP would take longer due to the additional network roundtrip between RP and old OP. Sounds like a trade of message size for backend state and latency. Do you really think the saved message size is worth this change? We are talking about a couple of hundred bytes.
On the other hand, if we change the design that way, we also need to investigate the impact on security. In the current model, the new OP can verify the migration data content and attest it to the RP along with its own user data. This is no longer possible with your proposal.
Regarding authz of the request to the old OP: Using access tokens would mean the RP needs to obtain an access token with the old OP, right? How would you imagine this to work? I would rather propose to put the identifier of the migration data JWT in the URL the old OP issues to the new OP (making it a URL pointing to a particular migration data resource).
3) Regarding time-to-live of migration proofs and the required verification key material: I think it would be wise if we gave some thought to how we want to enable RPs to verify migration proofs even if the original OP is unavailable/has retired the required key material.  Could we perhaps allow migration_data to have the alternate form
{
  "notarized": {
    "iss": "https://ttp.com",
    "iat": 1468925762986,
    "migration_data": "ey..."
  }
}

With the semantics that the signature protecting the encapsulated migration_data JWT was verified to the issuer's satisfaction at the given time?  This presupposes a service at the TTP that could verify a JWT signature and produce a notarized encapsulating JWT, and that the TTP pledged to keep verification key material accessible for a significant amount of time.  The RP could then, provided they recognize the issuer of the notarized claim as a trusted third party, use the payload section of the encapsulated JWT without themselves verifying the signature.  (RPs not happy with deferring signature verification can choose to ignore the notarized wrapper and verify the original signature themselves, accepting the life cycle risks of OPs and JWT verification key material.)
Looks like the introduction of a CA concept in the JWT space, which would make the spec significantly more complex. As I stated above, I want to keep the spec as simple as possible. How relevant is the use case in your opinion? I would be satisfied if we could support migration of user accounts in the general case (to start with). If an OP goes out of business (suddenly), no one could even start a regular migration process. I would rather assume that the user will need to reestablish access to its RPs using RP-specific recovery methods (or using alternative authentication methods at the RP).
Some detailed questions/remarks:
- How is the RP supposed to determine whether the old OP is still in business (and able to provide the key material) or not?
- Expiration of key material is a different use case (in my opinion). I think the whole migration process could/should be conducted again in this case.
4) On a minor note, it looks like the migration_data JWT in section 4 does not match the JSON shown below it, which I assume it is intended to.
You are right. I reworked all examples of signed migration data (and added some text regarding signing in section 3).
Thanks,
Arne.

On Tue, Aug 2, 2016 at 10:11 AM, <Torsten.Lodderstedt at telekom.de<mailto:Torsten.Lodderstedt at telekom.de>> wrote:
Hi all,

I just republished the draft in order to fix a problem regarding references (thanks to Axel!). You can find the new version at http://openid.net/wordpress-content/uploads/2016/08/draft-account-migration-01.html

best regards,
Torsten.

Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net<mailto:openid-specs-mobile-profile-bounces at lists.openid.net>] Im Auftrag von Lodderstedt, Torsten
Gesendet: Dienstag, 19. Juli 2016 13:30
An: openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Betreff: [Openid-specs-mobile-profile] New Version of Account Migration Draft

Hi all,

I just published -01 of the account migration draft at openid.net<http://openid.net> (http://openid.net/wordpress-content/uploads/2014/04/draft-account-migration-01.html). The source code can be found in our Bitbucket repo.

This is a significant rewrite of the specification based on your valuable feedback. Thank you! Although I tried to incorporate all review comments, please bear with me if I missed a comment. Please let me know, so I can incorporate it in the next revision.

I applied the following changes to the document:

•         reorganized the draft
•         extended introduction and overview
•         stated scope of the draft and what is currently out of scope
•         changed terminology from porting to migration
•         changed migration data structure to be different from an id token
•         cleaned up references
•         added initial security considerations

Please post your feedback to the list.

best regards,
Torsten.


_______________________________________________
Openid-specs-mobile-profile mailing list
Openid-specs-mobile-profile at lists.openid.net<mailto: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/20160804/f6d995fe/attachment-0001.html>


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