/
UMA telecon 2014-05-15

UMA telecon 2014-05-15

Owned by Eve Maler
Last updated: May 15, 2014

UMA telecon 2014-05-15

Date and Time

Agenda

  • Reminder: no meeting next week (May 22) due to absences
  • EIC report (if anyone is able to join from Munich)
  • Webinar planning:
    • Let's schedule a planning call
    • Leverage EIC session content?
    • Interest in sponsorships?
    • Technology to use this time?
  • Interop planning
  • Twitter handle management
    • Meshfire tool
  • Case study work
  • Regex style of resource set/scope registration
  • Multi-AS policy sourcing issues
  • Claim profiling work (if Maciej is on)
  • AOB

Minutes

Congratulations are in order

...to all UMAnitarians for UMA's win of an EIC award in Munich yesterday! Joni accepted the award on our behalf, and you can see Maciej and Domenico with the award here.

The IRM Summit is coming up, where Eve is scheduled to speak with Ian Glazer about a lot of UMA topics, and CIS is also coming up, where George is speaking on IoT. These are the next opportunities to do outreach.

Webinar planning

Eve is planning to set up a webinar planning meeting for her return from vacation. MIT is willing to sponsor, including:

  • Public support and association with the effort
  • Providing WebEx facilities; they have a "professional-grade" account
  • Monetary support for the press release

Justin Richer is currently on sabbatical, working at MIT to enhance OpenID Connect; the intent is to ask him to work on UMA. Board members that haven't even been part of the current conversation at MIT are asking about UMA + OpenID Connect support, including a hardware-oriented company. We're thinking we might leverage the Keynote slides that Domenico and Maciej presented at EIC, along with potentially any demo Maciej performed there.

Eve will send a note to the list asking for additional sponsorships so that we can be well-rounded.

  • Date: June 19, 8-9am PT
  • Theme: UMA, OpenID Connect, and personal data stores
  • Key participants: Maciej/Cloud Identity, Thomas/Justin?/MIT-KIT, Dazza/MIT, and Nat so far
  • Hashtag: #UMApcloud
  • Sponsorships: MIT, who else?

Interop planning

Mark described the IIW session where the topic was UMA interop. The session attracted some people who were new to UMA, and so a lot of UMA 101 material was discussed. The session concluded that Roland should fork his OAuth AS implementation, to build on top of OAuth as much as possible. UMA is quite a bit more complex because of the greater number of entities. You need to test an RS, for example, against two different entities.

We discussed the interop challenge of RS API vs. client behavior. As a result, we revised the requirements for what an RS has to declare about its configuration in order to participate; we took out the "pbryan" requirement. If the API has dynamic elements, the configuration info just has to specify where the variable data goes.

Case study work

Eve points out how LMP adds to the concepts of PDS, PDEC, etc. by explicitly naming the "advanced data-sharing models" behind the platform: informed pull and controlled push. Domenico's personal loan use case puts meat on the bones of informed pull, explaining how the requesting party can provide context to their request for authorization – akin to "meaningful use" standards in healthcare and "purpose of data usage" discussions more generally.

Thomas and Sal speak in support of publishing this on our Case Studies page. Sal expresses interest in following up with Mario Hoffmann on his proposal to get a project going and seek EU funding, and also in pointing to the new case study in the IDESG work.

What does ABAC mean to people? Does it mean "claims-based authorization", or policy-based access based on the entirety of the authorization context presented by the requesting party? The latter might include both requesting party/client-independent things like the time of day or the SLA, and "claim-dependent" things like promissory claims about the intended data purpose. George notes that the value of promissory claims really depends on the definitions given to them at circle-of-trust levels. E.g., an access federation might standardize – for its members only – the identity attributes (claims) of requesting parties, akin to attribute schemas in identity federations, and also the meanings of data purposes, validity period/expiration standards, and other semantics that are not able to be enforced at the technical level.

Thomas points out that you could simply do a claim profile to settle on the semantics of all sorts of authorization context that the client is required to provide (along with specifying how they have to be conveyed). "In order to grant authorization to this resource set and scope, I need to see the IMI number off the phone being used to run this client app." In SAML, it's the IdP that issues assertions based on the context, and it's the SP that consumes it. In our situation, the UMA client is (or speaks for) the assertion issuer, and the UMA AS is the claims client. We're still thinking that the power here comes from further profiling by third parties of our claim profiles. The semantics tend to be really ecosystem-specific.

On Mark's work on the PCAA case study, he did get a chance to talk to Phil Windley about the topic. He'll continue thinking about and working on the writeup.

On IoT use cases, George is speaking on this subject at CIS! We hope to make real progress on publishing IoT case studies by July at the latest. His emails on "Device-Managed Access" to our list are provocative. Start with the presumption that anytime a message is sent, it should have attached to it some measure of authorization, and anytime a response is sent, it should come with some measure of authorization. Think about a thermostat that is Internet-enabled. Turning on the heat etc. needs to require scoped authorization. If you are a constrained device and receive a request message, in what way do you need to be an AS so that you can assess the RPT that came with the request?

A common use case would be "adding a device to my personal cloud". So if there can be some introduction protocol that's optimized to use Bluetooth LE or whatever, that would be valuable. A phone could communicate to the new device, "Here's my AS." The device can send back to the phone "Here's an identifier for me." This could use a "software statement", which is the chunk of metadata defined by the OAuth dynamic client registration draft. At manufacture time, you don't have to do crazy PKI-enabled logic; a simple signed JWT could be wired in to be communicated to the phone once purchased. So the individual can successfully and securely execute on the task "Add this device to my family room." The AS will already know that the software statement is good, and can provision keying material to a preconfigured RPT. Some pertinent questions:

  • What in the spec would have to change to enable a pre-provisioned RPT?
  • Does dynamic client registration in this circumstances tantamount to getting an AAT because it's two-legged?
  • Can you get a preauthorized RPT with a "fixed" permission ticket?
  • Would there need to be client pre-knowledge of scopes and APIs, pre-establishment of an AS relationship, etc.?

We think there's an opportunity here to use the Authorization API Extensibility Profile, and then write an extension profile that locks down interoperable choices for IoT operation. Thomas notes that devices that use the TPM have an X.509 cert already provisioned into the hardware. This is good news (proprovisioned!) and bad news (X.509! (smile) ). At the end of the day, we're going to need to bind an unsigned device into a circle of trust. The relationship may be temporary, so dynamicism in adding it to the network and removing it from the network is required. The OAuth registration stuff around provisioning keying material is interesting for this reason.

Attendees

  • Eve
  • Thomas
  • Mark
  • George
  • Zhanna
  • Sal

Next Meetings

  • No meeting Thu May 22 due to absences
  • All-hands meeting Thu May 29 8:30-10am PT (time chart)