[Openid-specs-mobile-profile] Account porting example updates

[Manger, James]

> - Why is GET instead of POST for the checking call?

Theoretically GET was a better match for the semantics: retrieving the status & subject id for a port. The request should be idempotent. It isn’t particularly making state changes to the server (Old OP). However, I agree that POST is better in practice. Caching isn’t important here; the encrypted port token is like a credential; and it isn’t that small (eg ~650 bytes).

> - … why the Old OP should check the sector id or redirect uri host of the RP

It is a privacy check. It prevents an RP from sharing an enc_port_token with another RP, which would enable both RPs to correlate the pairwise subs they get from the Old OP for the user.

It is a SHOULD (not a MUST) because of corner cases with OP’s that don’t use pairwise subject ids. For instance an Old OP issuing the same “sub” to all RPs might not know an RP’s sector_id (since it doesn’t need it to calculate “sub”), but there wasn’t any privacy benefit from the check in this case anyway.

Some extra text to explain this should be added.

--
James Manger


From: Torsten Lodderstedt [mailto:torsten at lodderstedt.net]
Sent: Monday, 20 March 2017 5:26 AM
To: Manger, James <James.H.Manger at team.telstra.com>
Cc: openid-specs-mobile-profile at lists.openid.net
Subject: Re: [Openid-specs-mobile-profile] Account porting example updates

Hi James,

I think the spec is in really good shape. Thank you for bringing it forward!

I’ve got two questions:

- Why is GET instead of POST for the checking call? GET requires the RP to send the encrypted port token, a credential, as URL query parameter. I think it would be better to send it as body parameter in a POST request.

- I haven’t found an explanation of why the Old OP should check the sector id or redirect uri host of the RP. As far as I remember this is a further mean to ensure the same RP is calling on both ends, the new and the old OP. Would it make sense to add this explanation?

best regards,
Torsten.

Am 14.03.2017 um 02:14 schrieb Manger, James <James.H.Manger at team.telstra.com<mailto:James.H.Manger at team.telstra.com>>:

I have updated the examples of an encrypted port_token in the account porting draft. The previous example values had some bugs:
* They couldn’t be fully checked because only a partially-elided version of the Old OP’s public key was present. Now the complete Old OP’s public & private key is in an appendix.
* There were some commas missing from some JSON.
* The AES-GCM calculation (ciphertext with tag) wasn’t correct.

We are 8 days into the 45-day Implementer’s Draft public review period<http://openid.net/2017/03/06/public-review-period-for-four-modrna-specifications-started/> that links to draft 07, while the corrected examples are in the subsequent Editor’s Draft<https://id.cto.telstra.com/public/openid-connect-account-porting-1_0.html> (the current version in the Bitbucket repo). I’m not sure what to do about that. Perhaps the corrected examples are a minor change that can be reflected with a comment and updated links on the blog entry about the review/vote (and WG page)? Or perhaps a 2nd Implementer’s Draft is reviewed/voted-on later with these changes and any others that the current review flushes out?

--
James Manger

_______________________________________________
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/20170320/e4940867/attachment-0001.html>