Messages - 3.1.4[.1]. errors in fragment cases should be cared?

[hideki nara]

A [[http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20111003/001129.html | Discussion in ML]] may be cared here.

[hideki nara]

Because the Token Endpoint returns id_token if request scope has openid, prohibiting "response_type=code [id_]token" may make things simpler.

[John Bradley]

There are RP who want the id_token in the response from the authorization server. That way they can quickly customize the UI without waiting for a response from the token endpoint.

We can't remove that option.

Yes the reference is to the code flow error and not the implicit flow error. that needs to be fixed. That should be part of the return type registration.

[hideki nara]

I know there must be a option for RP to receive id_token in URL fragment. But in such cases, RP can expect access_token to be returned in fragment too, which means that "return_type=token id_token".

I know that we must to care the cases when the a size of token+id_token exceeds the HTTP limit. I'm just less comfortable about OAuth MUST return code only in query part of URL(OAuth 4.1.2) but Connect is going to allow code to be returned in URL fragment. If OAuth allow Servers to return code in URL fragment(I think it'll work), it wouldn't be problem.

But I'm happy if OpenID/Connect works fine anyway.

[John Bradley]

I changed both messages and standard to make the response types clear about how the errors should be returned.