Versions Compared

Old Version 1

changes.mady.by.user Eve Maler

Saved on

compared with

New Version Current

changes.mady.by.user Eve Maler

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

UMA telecon 2015-10-

...

15

Date and Time

Agenda

  • Public Review status and outstanding comment review
  • New UIG text discussing default-deny
  • Interop and IIW planning: report from the UMA Dev group
  • Considering our Independent Submission stance of record
  • Considering charter revisions/cleanup, especially in light of any decisions on the previous item
  • Permission registration extension spec idea
  • How are we doing on other outstanding AIs?
  • AOB

Minutes

Public review status

Please retweet the @UMAWG tweet about the public review!

Take a look at the new Release Notes document.

UIG status

For the Organizations as Resource Owners and Requesting Parties section, is there really that much to say? Mike's folks are developing a sample resource server and an UMA client in Python, and will use the client credentials flow. His use cases typically use this grant flow. This will be Hello, World level. The org=RO circumstance is always the case for Mike, but the RqP might be an org or a human.

For the Ensuring Resource Server Access to an Authorization Server When the Resource Owner Is Offline section, it's worth pointing out that the RO might not be a human at all, in which call "offline" isn't the right word. We might also want to mention "break glass" as a phrase specifically, since everybody knows this phrase. We don't want to burden developers with trust framework knowledge, but it might be a good idea to call out to the Binding Obs at this point, because it's around here that UMA protection might tip over into enterprise access managementThere appear to be no big comments yet. We have a few editorial/minor text comments. We should be prepared to vote on edited versions of the specs on Nov 5, and make quorum.

Eve and Katie have been getting quite familiar with using the V1.0.1 versions of the specs. Mike and folks will be looking closely at them for OxAuth purposes.

AI: Eve: Publish low-level UMA swimlane and WSD source code (with new V1.0.1 spec section references) for general use.

Mike's diagram (currently up to 33,708 hits!) seems very popular.

Robert notes that the diagrams by themselves, without a narrative, kind of start in the middle (or at the end). Should we be providing a new area of the site for videos, training, documentation, etc.? Stories from the Alice and Bob perspectives could be good too. Intro to UMA? UMA 101 would be ambiguous. (smile) UMA for Beginners? And then we could have Advanced UMA materials etc.

AI: Mike: Create a new UMA video/screencast.

An interesting discussion as part of this intro material would be a discussion of best practices around scopes and scope design. See, e.g., this page that catalogues Google API scopes that are actually used.

AI: Eve: Create new wiki area for UMA intro material.

Report from UMA Dev

Roland will have some RS library work done by IIW. Mike also has a sample library effort going, at the level of Hello, World. We can perhaps combine efforts under UMA Dev to accelerate that effort.

Who from this call is at IIW? Eve, Mike, Adrian, Sarah, Maciej, Jin, Justin. Surely we'll convene a session on this topic, if not more.

Independent Submission

Originally the WG had planned to contribute our specs to IETF, with the hope/anticipation that the OAuth WG might pick up the specs as part of its work stream.

Subsequently, when Kantara softened its requirement for contributions elsewhere, the WG had decided to go the Independent Submission to the RFC Editor route (resulting in Informational RFCs) because of the value of the RFC imprimatur and the relative lack of likely impact on the specs through that process.

Now we are reconsidering.

Pros of going the Informational RFC route:

  • The RFC imprimatur does seem to be valuable to some; Debbie has noted this.
  • The specs get more "marketing".

Cons:

  • The process of AD review (and, possibly, WG attention) is onerous.
  • The confusion around multiple versions of specs, KI vs. I-D, is potentially considerable.
  • The original motivation for contributing I-Ds was that people in IETF don't pay attention to spec input unless it's in the I-D/RFC ecosystem, but that hasn't help our cause to date, as far as we can tell.

Justin proposes updating the I-Ds we've got now with I-Ds that have no content except for URLs that point to the "real" specs.

Justin notes that his implementation of RSR in the non-UMA context, prior to implementing it for UMA, had to be changed considerably to work with his later UMA implementation. So maybe it's not as modular as we think.

Can we learn more about Debbie's rationale? If we do go the Informational RFC route, in fact it wouldn't go through an IETF WG; does that impact her thinking? Andi cautions that some who are interested to deploy UMA may not take it seriously if it doesn't come through a certain organization.

Mike looks at the SEO/marketing angle. Even with possible confusion, getting the specs out there through more channels would be valuable.

AI: Eve: We apparently need more information about who would reject UMA if not published as an RFC; float the question with those who care about this.

Permission registration extension idea

AI: Eve: Send email about permission registration extension ideas.

Previous AI status

  • AI: Thomas: Review the charter for potential revisions in this annual cycle.
  • AI: Sal: Investigate IP implications of formal liaison activities with other Kantara groups with the LC, and ultimately draft an LC Note as warranted.
  • AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve to add to the FAQ, pointing everyone to the UIG.
  • AI: Mike: Write SCIM protection case study to highlight client claims-based use case.
  • AI: Andi and Zhanna: Please look at the section on optional and extension properties to see what might need an update to account for V1.0.1. [DONE]
  • AI: Maciej: Review and correct the Redirecting the Requesting Party to the Client After Claims Gathering section.
  • AI: Maciej: Write up some recommendations for the RPT Refreshing section.
  • AI: Maciej: Try to find Justin's old recommendations for the Permission Ticket Management section.

Attendees

As of 13 Oct 2015, quorum is 7 of 13. (François, Domenico, Sal, Thomas, Andi, Mary, Robert, Maciej, Eve, Sourav, Lisa, Arlene, Mike)

...

  1. Eve
  2. Andi
  3. Arlene
  4. Mike
  5. Robert
  6. Maciej

Non-voting participants:

  • tbs

Regrets:

  • tbsDavid Maisenberg - attorney (non-practicing) - works with biotech - didn't know about UMA but was looking for it! - trying to get up to speed - hopes to contribute to writing and research - based in Colorado
  • Sarah
  • Steve Greenberg - technologist/consultant - obsessed with delegated consent and identity - following with interest
  • Adrian
  • Katie
  • Justin
  • Ishan
  • Jin