UMA telecon 2013-12-12

Date and Time

• Focus meeting Thu Dec 12 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

• Reminder about the meeting schedule in the rest of 2013
  
  • All-hands next week, then no more meetings in 2013
• Spec refresh plans

  • RSR 2.1: s/scope/Scope/ at beginning of sentence

• Interop plans for early 2014
  • Call a meeting of interop participants?
  • Feature test status?
  • F2F interop opportunities
• Healthcare use case technical and educational efforts
  • Use case results so far
  • Additional ad hoc meeting this month?
  • Upcoming healthcare IT-related meetings and conferences?
  • PHealthCloud demo script?
• Resource description and SAML+UMA attribute release use cases
• AOB

Minutes

Spec refreshes

AI: Eve and Thomas: Refresh RSR spec as well, fixing typos in it first?

Interop

Mark may be starting his implementation project around early 2014. We note that IIW and EIC in May present good opportunities for F2F "showcase" interops; any opportunities before then? Maybe RSA

AI: Eve: Call a meeting of potential interop participants in ~mid-January.

Regarding the F-pat and F-aat feature tests: Rather than having open-style optional tests for other grant types, we will add a single optional SAML-based feature test. We won't bother with testing the generic other-grant-types pattern at this juncture.

AI: Thomas: Spec edits: Update the SAML bearer profile doc reference in Core; it's currently up to Dec 9, 2013. Also, the repetition of the "valid PAT" statement in Core Sec 3.2 should be removed as appropriate.

F-rsr feature tests: We currently have FT-as-rsr-scope-display as optional, but really, there's nothing in any technical spec that forces this at all, in order to make it technically testable. So we have two choices: 1) Design a way for the RS to sign or otherwise cryptographically secure the stuff it's registering so that when the AS displays it, there's some sort of "trustmarking" you can do, or 2) Think about putting something in the Binding Obs as a stopgap to force the AS to promise to the RS that it won't misrepresent the scope names, icons, etc. We removed the feature test in question because it matches nothing in the specs.

AI: Eve and Dazza: Take up question of AS-to-RS promise about scope display.

AI: Thomas: RSR 2.1: s/scope/Scope/ at beginning of sentence.

AI: Eve: Add an RSR spec issue about whether it's worth adding OAuth-layer error conditions such as malformed_scope_desc and even status conditions like scope_desc_not_retrievable.

Healthcare use case

We will meet again 10-11:30am Pacific on Wed Dec 18 to FINISH the work. Roland is interested to provide the sample apps we can use to give color and live demo capabilities to the PHealthCloud. Mark plans to attend a healthcare conference early in 2014 in The Netherlands.

AI: Eve: Put last IDESG use case ad hoc meeting in the UMA calendar and confirm that we can use our usual dial-in.

AI: HC folks: Work on PHealthCloud demo script at least by early January.

AS=C and RSR issues

We're inclined to advise Roland that the RSR channel should not be used to push resource (attribute) values without a super-good reason, because it's a config-time channel for a different purpose, and amounts to bulk-synchronizing data (where bulk-sync implies latency and stale data). We haven't decided yet on what to do about AS=C optimizations, other than to rule out the RSR channel for doing so!

AI: Mark: Propose spec text around "option 3" for AS=C, exploring the potential for turning off some MUSTs around the requirement for AS and C to communicate through HTTP API endpoints.

 Attendees

Next Meetings

• 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)