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

[Manger, James]

Torsten,

draft-account-porting version 03 fixes some of your comments:

-----Original Message-----
From: Torsten Lodderstedt [mailto:torsten at lodderstedt.net] 
Sent: Sunday, 16 October 2016 12:06 AM

.
> 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.

DONE. §1.2 "Porting flow"


> 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.

DONE. Deleted reuse sentences. Said New OP MUST include sector_id, which prevents the potentially dangerous misues.


> - 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.

DONE. §4 says enc_port_token is opaque to an RP. Only OPs have to care about §4.1. "Encrypting port_token".


> - 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.

NOT DONE. Other options could be added, but more choices make interop harder.


> - "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).

MAYBE DONE. The spec matches sector_ids (domain names), not sector_identifier_uris (scheme+domain+path).


> 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.

NOT DONE. If "iss" is part of the Old OP's response it introduces the risk that a malicious Old OP returns another OP's "iss". So RPs would have to check that "iss" was the expected value (in which case, why not just use the expected value the RP knows). The one benefit of returning "iss" (and the RP checking it) is it prevents a malicious OP putting a port_check_endpoint in its metadata that points to another OP's Porting check API. I'm not sure if that is bad or irrelevant.


> - 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.

HOPEFULLY DONE. §4 "aka" explicitly talks about "aka" in id_token or a porting check response.

>- 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.

NOT DONE. It is out of order (client cred flow is at the end of the section, but must be done first). But is can be done somewhat independently; done once, not once-per-user; is standard OAuth, not special to porting - so it is tacked on the end.


> 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)

NOT DONE.

--
James Manger