Monday, March 23 2020, 20:00-22:00 UTC
Chairs: Dick Hardt, Yaron Sheffer
Minute takers:
Bron Gondwana
Lee McGovern
Rob Wilton
Chair slides, agenda bashing - Dick and Yaron - 10 min.
Charter discussion, discuss WG name) - 20 min. https://mailarchive.ietf.org/arch/msg/txauth/G7kcSqApAkKrdjnr0NfKOTu1eRg/
XYZ - Justin (with Q&A) - 20 min.
XAuth - Dick (with Q&A) - 20 min.
Discuss differences between protocols - Yaron, Dick, Justin - 40 min.
Next steps - 10 min.
Yaron and Dick introduction
Where we are right now
20 in favour of txauth working group, 1 opposed
Agenda Bashing:
Annabelle: we should add more structure than just 20min for agenda bashing, concrete use cases to be defined not just solutions
Identity:
Mike Jones: Identity is a lot of different things, we should scope it to an achieveable level.
Roman Danyliw: what would you be looking for that's different to current charter language.
Mike Jones: Want some use cases written down, what are the likely roles, why is a unique solution needed, ..., what are we reusing? Want to focus on reuse.
Dick Hardt: the charter states that we are covering the OAuth and OpenID use use cases
Mike Jones: Identity is many things, are you including the logout parts? Charter is not clear on whether you are building an end-to-end identity solution.
Dick: Reuse what has been done before is what we want to do.
Anabelle: Most obvious use case is the ability to support authentication protocol like OpenId Connect over TxAuth. Whatever protocol we come up with, we should be able to come up with a full Identity solution on top of it. Perhaps charter should be less about we are going to identity and more that we are going to enable identity. ??? Possibly with OAuth2 you can end up with access to a different resource in a different account? Share session management is missing in OAuth2, and would like to see it here. Would like avoid multiple structured languages, e.g. one for resources and one for claims? Would end up being unnecessarily complex.
Ben Kaduk: 2 points:
By identity, perhaps this is just a type of information that is being carried.
Cullen Jennings:
??? What use cases are not already covered by existing protocols.
Are we repeating the work that other SDOs are doing in this space? If so, great, but that needs to be clear in the charter. Say that.
Yaron: I think that the charter does cover
Cullen: I thought that OAuth2 would cover the usecases, so some clarity in the charter would be helpful. E.g. is it just covering usecases.
Dick: A number of OAuth2 things that don't work. Can solve some identity issues. If they deploy OAuth then they would want xxx and identity. ???
Justin Richer: ??? TxAuth should be able to convey ... Should have basic hooks, lots of OAuth2 based protocols that are not OpenIdConnect. WG needs to decide where to pull the credentials? from. Charter should not assume the answers.
Anthony Nadalin: Still missing why Identity would be in scope of the charter but ??? isn't. Lots of other groups doing work in this space.
Dick: Goal of the charter is to reuse existing stuff, not reinventing stuff.
Ben: Clarification question Dick, your goal is to get clarification in the charter about both how we are going to reuse existing authentication technologies and the binding between that and the identity information that we convey
Dick: ????
Mike Jones: If only release identity claims at auth time, then guarantees that there will need to build additional layers, e.g. session management, logout, cookie management, etc. Would rather there is a claim? layering. Decide where to do the cut for layering. Identity is a really big topic. Would be more like to succeed by refactoring authentication. Regard TxAuth as giving a different response type, identity stuff should be the same. Charter is ambiguous as to whether session management is in or out. As per AD comments, this needs to be clarified.
Torsten Lodderstedt: Identity is a big topic, focus on auth protocol. Agree incremental auth is solved/not solved??? problem. Would like to see upgrading a user from an existing authentication. Second usecase is providing identity between AS and RS? Need to cover Client to AS to RS, and RS to Client? Would like to see support in the new protocol for ways to manage tokens, single and multiple access token designs. Have some proposals that are covered by the current charter text. Charter doesn't cover interoperability and testability.
Yaron: Charter text doesn't cover xxx?
Justin: Small handful of changes to the charter that have been incorporated by not publicised.
George Fletcher: Not trying to solve identity at all. Instead we are trying to solve standards for communicating identifiers and claims related to authorization elements. Perhaps if it was framed the charter in those terms (not solving Identity but identifing hooks into existing systems and the intersection). Need to hook into existing tools. If the scheme is about core identifiers ... that would be much clearer. Those (Identity management flows) should be out of scope for TxAuth ... and only looking at the intersection where it applies to Authorization.
Yaron: Any comments on the charter that are not on identity, speak now.
Mike: Need to do a hum as to whether we do session management, identity or layering. Charter has to say. Today is ambiguous.
Roman: Very tricky to do hums on Webex. Need to take to the list. The high-level concerns on where the charter required clarity:
XYZ - Justin (with Q&A) - 20 min.
session management was never intended to be in scope
Questions will be in the discussion section.
XAuth - Dick (with Q&A) - 20 min.
Comparison slides on differences between the 2 documents:
Annabelle: Very important for client to be able to request multiple capabiltiies. Client may not exactly know whether it can successfully redirect. It may not know the end mechanism which the end user might want to do. End user might prefer an indirect flow instead. Prefer to give the end user the option to move forward with.
Dick: I agree. Client knows what it can do. Can GS get the user back to the client or not. In XAuth, if indirect, GS sends short URL + display URL, client can decide what to do. User gets to choose.
Justin: XYZ signals the same thing using the "callback" mechanism in the interaction request
Annabelle: Looks like the client chooses one of the other.
Dick: By redirect, mean can GS redirect user back to the client?
Annabelle: Whether or not that is possible may depend on the environment. Direct route might work, but indirect route might not work. E.g. if app is running whether the client is capable of opening a browser, but a client might not want that to happen.
Dick: Assume client to be one scenario or the other. GS might choose not to interact with clients that indirect.
Annabelle: I agree this is an Important security property. Don't think it is necessary to couple redirect to the GS and the ability to redirect back to the client.
Justin: It is that decoupling that drove us to the design in XYZ. Example, users might be able to go to a web page, or might be able to go to a app on an agent on a device. Auth service might be able to support both of those. Still separate from ...
Annabelle: XAuth seems to be rolling a new client authentication mechanism. Wondering why. Don't think that this is the right place to be doing this.
Dick: We are using JOSE. Like any mechanism, it needs to be bound to the protocol.
Annabelle: Retract the RS side of the issue, but still think that this is a new auth mechanism.
Justin: If architecture can keep bytes of Jose object intact then it can keep the bytes of the JSON object intact.
Mike: XYZ claims slides, had some coming from JSON registration schema? and also some that it makes up. Seems to be making up a new schema. More in favour of starting with XAuth because it is not trying to reinvent a new identity schema.
Justin: Don't want to reuse all of OpenId or SCIM, or ... This should be a working group input, and shouldn't be part of choice of the solution.
Discussion will continue on the mailing list.
Will discuss with the ADs - whether to make changes or have new consensus call on charter.
Need to refine the scope, need clarity on that scope.
Next step is to take the feedback back to the mailing list and update the charter text. Need to decide whether that can be done as a diff, or need to update the charter text.