[Openid-specs-mobile-profile] Issue #50: Authenticate RP to Old OP during porting (openid/mobile)

Torsten Lodderstedt torsten at lodderstedt.net
Sat Oct 15 13:05:52 UTC 2016


Hi James,

Am 07.10.2016 um 08:59 schrieb Manger, James:
> https://id.cto.telstra.com/2016/openid/draft-account-porting.html
>
> I have updated the Account Porting draft to authenticate RPs to the Old OP; resolving issues #49 and #50.
> Comments welcome.

Thanks for creating the new revision, here are my comments:

I think it makes sense to give an high-level overview on the message 
flow among RP, new and old OP in the beginning of the document, e.g. 
after section 1.

section 4.1:
- "A New OP can reuse an "enc_port_token" for logins to multiple RPs 
that share the same "sector_id", but can also calculate a separate 
"enc_port_token" for each." - Why do we need to state anything about 
reuse of encrypted porting tokens? Isn't this just an optimization? I'm 
concerned this optimization could open privacy issues if RPs use the 
same sector_id with the new OP but different sector ids with the old OP.
- We should add some text saying that the payload of the porting token 
is anyway opaque to the RP so it does not need to worry about it.
- I think using the new OP's client secret with the old OP to derive the 
encryption key as the only option is to limited given OIDC allows to use 
assertions for authentication purposes as well. We potentially should 
come up with a consenous in the working group whether we will recommend 
public key based authentication mechanisms as an option in all our 
specs. In this case, migration should support it as well.
- "SHOULD verify that the "sector_id" from the JWE header (if present) 
matches the value for the RP. The only exception to this is when the Old 
OP uses public Subject Ids and does not know the "sector_id"." I think 
this could be to restrictive. The purpose of this member was to identify 
attempts of a single RP to obtain multiple (ppid) subject values using 
the same porting token (even if we need to assume the sector_id is not 
excactly the same). As far as I remember the idea was to at least check 
the host component of the sector id for equality (or to use other shared 
knowledge about the RP for that purpose).

section 5
- I think the iss should be contained in the porting data along with the 
subject sub as it is always being interpreted in the context of this 
particular iss.
- I assume the old OP uses the porting token obtained from the (even) 
older OP to create the "enc_porting_token" in the aka member? In my 
opinion, some text about this and a reference to the way encrypted 
porting tokens shall be created would helpful.
- I was rather surprised to see an client credential flow example in the 
end of this section. I recommend to move paragraph 2 of this section and 
(even better) to an addendum.

>
> The approach uses OAuth so there is an additional request to swap a client_id/client_secret for an access_token before calling the Porting check API. This has its cons: an extra request; reuses the RP's client_id/client_secret for interactive logins (code flow; acting on user's behalf), and backend API access (client cred flow; acting on RP's behalf).

I think it is imperative to use the same client_id for both flows since 
the old OP needs to relate the RP on both interaction points in order to 
come up with the correct client policy and ppid. I also think the RP is 
acting on behalf of the user in both cases (although the access tokens 
might refer to different identities).

If we want to omit the extra request, we could also turn the port 
checking API into a new grant type and use the tokens endpoint to 
retrieve the porting data.
pros:
- less requests
- same response handling as for ordinary login requests (including aka 
handling!) - the porting data would be returned in the ID Token, the 
additional access token can be used to access user info at the old OP 
(if that's needed in curse of the migration)

best regards,
Torsten.

>
> Other changes:
> * Dropped the unencrypted port token option, which was a simplification if public (non-pairwise) Subject ids were used.
> * Added text to the "Encrypting port_token" section about nonces; also moved the section.
> * Dropped the sector_id query parameter from the Porting check API
> * Explicitly listed half-a-dozen checks the Old OP MUST do for the Porting check to be secure
>
> The new version is in the repo draft-account-porting.{xml|html|eg.png|eg.uml} https://bitbucket.org/openid/mobile/src and on my website https://id.cto.telstra.com/2016/openid/draft-account-porting.html.
>
> To do:
> * Add "move" vs "link" support
> * Proper example values
> * Describe which parts concern RPs, New OPs, and Old OPs
> * Privacy considerations (porting lets another OP see all your logins; interesting corner-cases if Old or New OP uses pairwise subs while the other uses public subs)
> * Check security considerations (haven't been touched from earlier proposal that was quite a different mechanism)
> * Demo implementation
>
> --
> James Manger
>
> -----Original Message-----
> From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of James Manger
> Sent: Wednesday, 5 October 2016 2:55 PM
> To: openid-specs-mobile-profile at lists.openid.net
> Subject: [Openid-specs-mobile-profile] Issue #50: Authenticate RP to Old OP during porting (openid/mobile)
>
> New issue 50: Authenticate RP to Old OP during porting https://bitbucket.org/openid/mobile/issues/50/authenticate-rp-to-old-op-during-porting
>
> James Manger:
>
> draft-account-porting-01 assumes an encrypted port_token is basically a bearer token allowing the RP to call the Old OP to complete the porting flow without further authentication.
>
> The Old OP is effectively leveraging the authentication of the RP by the New OP. This is awkward when the Old OP and New OP don't identify RPs in exactly the same way. Old & New OPs will have separate client_ids for a given RP so that doesn't help. Old & New OPs should both understand the same sector_id for an RP. However, sector_ids might not be properly implemented everywhere. In particular, an OP that issues public subject ids doesn't uses sector_ids.
>
> See [email thread](http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20160926/000598.html).
>
> Responsible: james_manger_telstra
> _______________________________________________
> 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



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