OAuth and SASL / Open Issues “to http or not http….”

OAUTH+SASL Open Issues (T2K)

Convener: Bill Mills

Notes-taker(s): Bill Mills

Tags for the session - technology discussed/ideas considered:

Reviewing outstanding issues in the current draft, notable the current HTTP style format and auth endpoint discovery.

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

• Simon asked about GSS-API bindings, can we make this stronger and use this for bootstrapping GSS-API mechanisms.
• Discussion about “To HTTP or not to HTTP” which ivolved into the next item. In general:
  • HTTP is seen as a bad option here, which we knew.
  • If we’re going for a new format the feeling was that we should not try to build in anything extra in the short term and that new tokne profiles should define their own extensions to the base framework.
• Detailed dscssion of the flow. A *great* question was asked about discovery, that in the case where we have multiple potential IDPs, we have a big problem because all IDPs have to provide compatible access tokens to the protected resource. This needs to be looked at seriously.
• *Need to add text here that federated login and the password grant are almost incompatible. The solution is probably to make the IDP for the PR be populated with a password to be used for things like IMAP when in fact there is a federated auth situation with multiple IDPs. This is still outside the true scope of the spec but is well in scope for security discussions.
• Discovery is still very hard, and it is becoming clearer that supporting the password grant is probably the legacy support case and that federated login and the OAuth 2 password grant are probably really incompatible, because a protected resource sever can cause a client to give up the password to the wrong place.
• Discovery in federated situations almost certainly has to point to the domain discovery endpoint, and the client has to discover further, potentially an OpenID connect flow or other flow rather than the password grant.