OATH 2 Dynamic Client Registration

Session Topic: Oauth 2 Dynamic Client Registration

Wednesday 5I

Convener: George Fletcher, Tom Brown

Notes-taker(s): Tom Brown

This session combined 2 proposed sessions.

There are 3 outstanding specs related to dynamic client registration

1. OpenID Connect (push)

2. UMA original (push and pull)

3. Oauth 2 IETF draft (push)

Lots of commonality across specs

Self-asserted: hard to verify (client type, for instance)

Oauth 2: how client id and secret is distributed is out of scope

You have 2 different classes of clients (beyond public vs. confidential) that need to be treated different

Should AS restrict what data it gives out based on what was provided? (web page, phone number, etc.)

Security:

1. DOS attack

2. scope

3. client mimicry – human facing metadata → mitigation: explicitly display return to url

4. authorization trust of registration request

IETF draft will probably reabsorb OpenID Connect additions

The complexity for the AS to do the right thing is growing.

The use case of a native open source mobile client with authorization code flow, not using a custom scheme was considered where the open source project did not want to mandate the callback uri. It was suggested that if the mobile app does not send a callback uri, then the provider will provide its own for the browser authorization. It was noted that facebook does something similar for callback uri.

There is no place in the Oauth spec where you send Json. Perhaps pushing form data is better.

Justin will proceed with resolving remaining differences among the specs.