UMA telecon 2013-11-21

Date and Time

• All-hands meeting Thu Nov 21 8:30-10am PT (time chart)
  
  • Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines), room code 178-2540#
  • Screen sharing: http://join.me/findthomas

Agenda

• Roll call
• Reminder about the meeting schedule in the rest of 2013
• Roland H implementation demo
• Resource description and SAML+UMA attribute release use cases
• Plan interop activity and communications
• AOB

Minutes

Roll call

Quorum was reached.

Approval of minutes

MOTION: Approve minutes of UMA telecon 2013-10-31, and read into today's minutes the notes from all focus meetings held since 2013-10-31. APPROVED by unanimous consent.

Roland H implementation demo; resource description and SAML+UMA attribute release use cases

Roland presented his implementation. There's a SAML IdP that is also an UMA client. The RS contains the identity information about the RO. UMA is being used to control attribute release. The IdP wants to get data from the RS and provide it to the SAML SP app. The IdP is controlled by the RO's AS regarding whether or not it's okay to release it.

He has chosen to make the resource set description pass the actual attribute value, and to provide scope URIs that represent attributes that are part of that resource (attribute) set. He did this for performance reasons, to lower the amount of RS-AS traffic. (Eve has wanted for a long time to tackle the problem space of attributes-as-UMA-protected-resources, since we knew we'd run into specialized challenges around this. Let's discuss it more in the coming weeks.)

 Linda the RO is able to set up release policies beforehand (preauthorized access). She can choose the resource set and the possible SAML SPs. There's a policy creation interface where Linda can add, delete, etc. permissions. There's an option to release an entire attribute (including potentially multiple values), or specific values such as a particular email address but not others associated with that overall attribute type. Roland showed Linda-to-Linda sharing through this means.

George comments: He's imagined that the UMA model would be AS-centric; in this model, it's IdP-centric. Andrew asks: What if the IdP were conceptually split into two parts, the "presentation" (interface to requesters) and the "back end" (the AS)? So this would be seeing the IdP as being the AS. But George notes that if users can choose their AS's along with having existing IdPs, then the AS could broker the ability of a variety of Linda's IdPs to get attributes from a variety of RS's/attribute providers. Roland confirms that this is one of his use cases. The other is that, in a university, you have a global research project where there are only one or two researchers from any one university, so that the IdPs have no incentive to manage attribute policies just for those two people. This gives the researchers the ability to personally set their attribute release policies.

 Does the SP send in a SAML attribute query and hope the IdP has a way to go find it? The SP's metadata has the list of SP-requested and SP-required attributes. This information could be used by the IdP when it asks the RS for attributes. How does the IdP find the RO's attribute provider to go and ask? The discovery isn't dynamic; it also has to be configured ahead of time. This means university admins don't have to worry about any config other than getting pointed to the metadata. Keith notes that in his higher-ed world, this model could be applied immediately if it's the right direction. For accessibility needs and preference (Alice-to-Alice sharing), where Alice wants the SP app to use high contrast in its UX, Alice could use this system to refer to her universal sharing preferences. This is "Alice's universal policy server".

 What about Alice-to-Bob (or Linda-to-Roger!) sharing? Could the policy server be used for this too? Roland notes that Alice could have set different release policies for different SPs with the same IdP, and the IdP/Linda (client/RO) combination has to authenticate itself, coming through a specific SP (since the flow being shown SP-initiated SSO). The IdP can assert to the AS, in a trusted manner, the identity of the user and the ultimate client. These can be considered "trusted claims". Note that the release policies gave Alice the ability to choose the targeted client from a dropdown list. This list is made up of IdP+SP combinations, since the IdP may work with a variety of SPs. If the AS could be crafted to consume SP metadata, that would be a great way to pre-load release policies into the AS as defaults. UMA says nothing about this, but it could be part of a profile in the higher ed/research community.

 The IdP speaks to UMA APIs as an UMA client. Thomas notes that MOOC situations require IdPs to deal with many different AS's, so that's another reason to fully separate the IdP and the AS. In the architecture diagram, the green parts speak SAML, and the yellow parts speak UMA. From UMA's perspective, there's only a single client in the picture. The IdP's right to aggregate attributes and distribute them further to the SP (which is sort of like a client but is invisible from UMA's perspective) is ensconced in its terms of service/trust framework with Alice.

 Domenico notes that in Italy they have been using SAML attribute aggregation and release policies for a while. So this could be interesting for public-sector entities. If you want to access public online services, you have to provide attributes like your role from different attribute authorities.

 AI: Roland: Create case study for research use case.

 Andrew asks: What if the RS gives access to a whole directory or data store? Would this mechanism be a way to turn the directory into a server of an individual's identity data? Absolutely yes. We can UMA-protect an XDI interface, a SCIM interface (which Gluu has already deployed), an OpenID Connect IdP or attribute authority interface, etc. But what about really old legacy repositories? Well, who would be the RO and define release policies? It could be either each individual user or the institution as a whole (a la Gluu's implementation).

Attendees

Prior to the call, Eve dropped Jeremy from voting participation. Quorum is therefore 6 of 11.

1. Eve
2. Jin

Next Meetings

• No meeting Thu Nov 28 (US Thanksgiving holiday)
• No meeting Thu Dec 5
• Focus meeting Thu Dec 12 8:30-10am PT (time chart)
• All-hands meeting Thu Dec 19 8:30-10am PT (time chart)
• No meeting Thu Dec 26 (holidays)
• Focus meeting Thu Jan 2 8:30-10am PT (time chart)