[Openid-specs-mobile-profile] Account porting: how to encrypt

Manger, James James.H.Manger at team.telstra.com
Wed Sep 21 00:52:12 UTC 2016


We shouldn’t need another secret.

I had forgotten about OIDC Core §10 “Signatures and Encryption” where use of client_secret (after hashing and truncating) as an encryption key is explicitly defined. That removes the downside mentioned earlier for option 2. Option 2 would reveal the New OP’s client_id (issued by Old OP) to all the RPs, but that shouldn’t be an issue.

Reusing (the truncated hash of) client_secret to encrypt porting messages, in addition to encrypting and decrypting other OIDC messages (id_token, UserInfo response, requests, client auth) would be fine if only JWT had a proper way to unambiguously define the semantics of a message!

How about option 2 with "iss":new_op, "sector_id", "cty":"oidc-porting", and "kid":client_id in a JWE header and a string from the Old OP ("port_token_plain" value) as the payload?

--
James Manger


From: Torsten.Lodderstedt at telekom.de [mailto:Torsten.Lodderstedt at telekom.de]
Sent: Wednesday, 21 September 2016 1:25 AM
To: Manger, James <James.H.Manger at team.telstra.com>
Cc: openid-specs-mobile-profile at lists.openid.net
Subject: AW: Account porting: how to encrypt

Hi James,

do you think this function is worth managing another secret? What about using the new OP’s private key to additionally sign the package containing the porting token?

best regards,
Torsten.

Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von Manger, James
Gesendet: Dienstag, 20. September 2016 06:27
An: openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Betreff: [Openid-specs-mobile-profile] Account porting: how to encrypt

The current idea for account porting is for the Old OP to provide a single token (which I’ll call port_token_plain) to the New OP; the New OP encrypts it (for the Old OP) before passing the ciphertext (port_token) to an RP; the RP passes it onto the Old OP; the Old OP decrypts it to retrieve the original token and returns the RP-specific subscriber id to the RP.

The per-RP (actually per-sector-id) encryption is necessary to preserve the privacy of pairwise subs.

An open question is how to do the encryption.

Option 1: public key and algorithm from Old OP metadata.
The port_token seen by an RP could be a JWE (compact encoding?).
One downside is that the encryption does not authenticate that is was done by the New OP.


Option 2: symmetric encryption with secret shared by the New OP and Old OP (such as the New OP’s client_secret used in calls to Old OP).
The port_token seen by an RP would be the ciphertext from an AEAD algorithm, keyed with the client_secret, using the iss and sector_id in the additional authenticated data.
This approach saves a few bytes, avoids some public key crypto, and avoids a metadata lookup to get a public key. A downside is that client_secret is not designed to be used as an AEAD secret key.

Any preferences?

--
James Manger

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


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