login_hint for Initiating Login at Client from Third Party needs work

[Brian Campbell]

A thread was started yesterday on this. http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130617/003692.html

And it was discussed on the Jun 20 call (though the scope expanded a bit in discussion and as is seen on replies to the tread above) http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130617/003699.html

The text at http://openid.net/specs/openid-connect-standard-1_0-21.html#client_Initiate_login could use some work, IMHO.

But, at a minimum, login_hint needs to be fixed. I'll propose the following rough text:

login_hint OPTIONAL. If the client receives a value for this parameter, it MUST include that value in the subsequent authorization request using the login_hint parameter.

or something along those lines.

[gffletch]

I tried to send this to list but not sure if it showed up or not.

I think we have two different use cases (at least what I heard on the call).

1. The initiator of the request only knows the login_hint value and therefore the URL only contains the login_hint parameter. In this case the OAuth2 client (receiver of the URL) must determine the identity provider via some mechanism and then invoke that identity provider also passing along the login_hint value un-normalized.

2. The initiator of the request only knows (or only wants to specify) the issuer. In this case the OAuth2 client (receiver of the URL) must direct the user to the specified identity provider. In some cases its possible that the client will be required to perform dynamic registration of itself to the specified identity provider before continuing the login flow.

It's mandatory for the client (Relying Party) to support both use cases.

As for the 'target_link_uri' it's pretty undefined as to what 'MUST verify' means. Maybe that's intentional, but as an implementer it's pretty unclear.

Overall, this "3rd party initiated" flow seems underspecified. Like we are leaving out processing rules and other things. Is it critical to have this support in the native spec as opposed to profile or secondary doc? Is support for this whole concept mandatory to implement for Relying Parties?

[Michael Jones]

Brian and John agreed to produce proposed text changes.

[Brian Campbell]

Why is this assigned to me?

My proposed text change is already in the issue description.

[Michael Jones]

I believe that we should apply Brian's proposed wording for login_hint as an errata change. I don't believe that we should specify George's case 1, in which requires the RP to do discovery based on the login_hint, as an errata change. If people want that feature, we should file a separate issue about it.

(As an aside, we need to add interop tests for third-party initiated login!)

[Michael Jones]

We will apply Brian's wording as errata - adding the word "string", per Nat's wording. We will not do the other proposed change as errata.

[Nat Sakimura]

I think it should state that it is a string.

For iss and target_link_uri, I proposed the following in the mail list. (For the purpose of recording it.)

login_hint OPTIONAL. A string that the client MUST send as login_hint parameter value of the authorization request.

iss OPTIONAL. Issuer Identifier for the Issuer that the Client is to send the authentication request to. Its value MUST be a URL using the https scheme.

target_link_uri OPTIONAL. URI of the target resource. After receiving a positive authorization response, the Client SHOULD redirect the user-agent to this URI. Clients MUST verify the value of the target_link_uri to prevent it being used as an open redirector to external sites.

[Michael Jones]

Fixed #850 - Clarified "login_hint" semantics for third party initiated logins.

→ <<cset 39bbe5f1bfcc>>