[Openid-specs-ab] Some more feedback on spec drafts

[Breno de Medeiros]

I had some time during a flight yesterday to read the documentation on
HTTP binding as well as UserInfo (didn't get to Session Management --
I think I will try my hand at a full re-write of that document once
the HTTP binding is more stable). I jotted down my thoughts

Here is the document I created:
https://docs.google.com/document/d/1qKGUUwhEiFuxe9QtFqc28vk1FObuXSw4NtKbyCSSMuY/edit?hl=en_US

Contents attached here for feedback:

HTTP Redirect Binding


Definitions


1. The HTTP Redirect Binding should make no references to the core,
including to the term definitions section

2. In particular, the following definitions from Core (that are
relevant to extend and framework, but not to minimal) should not be
provided in order to read the minimum:

- Claims, Claims Provider, OpenID Request Object
- OpenID provider should be renamed identity provider
- Questionable: Assertion, Entity, ID Token
- Credential is not defined
- Direct and Indirect communication are not defined

3. In the spec itself, the following definitions should be removed

- Artifact
- Request URI
- Request Registration Endpoint
- Request File

Overview


Should indicate the fact that the two flows can be used in combination
when a client consists of different components that both maintain user
signed-in state

Protocol Flows


The fact that indirect communication is not defined results in that
the protocol description in flows is subtly incorrect.

- Client sends a request to authorization server -> Client submits the
request to the User-Agent which forwards it to the authorization
server. For instance, the client may issue a 302 Http response to the
User-Agent with a Location header pointing to the authorization
server’s authorization endpoint with the request formatted as query
parameters of the Http Request. Or the client may set the
location.href property in a user agents’ child frame or window, if the
User-Agent is full HTML4 or 5 compliant client.
- User Agent submits the client-generated request to the authorization server
- Authorization Server authenticates the user via credentials
submitted by the User-Agent by means that are outside the scope of
this specification
- Authorization Server validates that the user has properly authorized
the request or interacts with the user to obtain such authorization,
by means that are outside the scope of this specification.
-  Authorization Server generates a response and submits it to the
User-Agent for forwarding it to the client. For instance, the server
may issue an 302 HTTP redirect response to the User-Agent with a
Location Header pointing to the client’s redirect URI and with
response parameters encoded as query (code flow) or fragment (token,
code+token flow) parameters.  Or the server may set location.href
property.

[Things that could also happen, but I am not sure whether we want to
include this in the spec: Or the server may issue an HTML5-compliant
cross-domain postMessage command with the JSON-encoded response. Or
(if the response_type is ‘none’), the Server may simply record the
grant, and simply return the user to the client via an HTTP redirect
or through history navigation.]

- Client processes the response in a flow-specific manner.

Suggestion: Rename id_token_audience to audience

Suggestion: Do not document the request and request_uri objects here
-- they are part of framework or messages

- There is precious little discussion of display values and prompt
values. There is no discussion about the requirement to support
implicit authorization (i.e., immediate mode).

I recommend that the discussion discuss code and ‘code + token’ in
parallel, with token being understood as being equal to ‘code+token’
with the code processing parts being ommited.

- There is no discussion of the token introspection endpoint. Id_token
is assumed. The opposite of what was agreed.

- The JWT format is mandated here, while there was agreement to leave
it to framework/messages

UserInfo


- UserInfo should not make reference to Core definitions, only to OAuth2



-- 
--Breno