OATH 2 Dynamic Client Registration
Session Topic: Oauth 2 Dynamic Client Registration
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.)
1. DOS attack
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.