UMA telecon 2012-07-12
Date and Time
Quorum was reached.
Approve minutes of 2012-06-21 and 2012-06-28 meetings
August IETF 84 meeting: anyone attending?
Possibly Eve and possibly Thomas (we're guessing).
Feature test progress
Eve and Trey, along with new participant Martin from UnboundID, met last week. The SMART team has registered themselves as a participant and also registered their three solutions. Fraunhofer hasn't registered itself or its solution yet. Eve will try and revise the feature tests and get them on the wiki for next week.
Fraunhofer AISEC has open-sourced its UMA implementation under Apache Amber. Fraunhofer consulted with the Apace community, and concluded that the Amber project is the best fit for their UMA implementation. They are planning to use UMA as the base for a project that involves downloading an app to share personal info with friends. Alam will share more news by the end of this month.
The development on the SMART side is progressing. No news on the open-sourcing.
#56: Standardized scope descriptions for well-known APIs
See Eve's email showing an example that applies to UMA itself.
Note that OAuth went for simple strings vs. URIs to avoid length problems in the case of involving a browser.
#58: Specify how to write UMA profiles
Peter had found SAML's guidelines for writing profiles enormously helpful, so let's base our spec advice on that example, and make it normative. We'll need two sections: general profiles and token profiles. Domenico notes that deployers might need profiles for different sharing constellations. Eve agreed and noted that something like an e-citizen use case might want a profile that requires the authorization code flow. Peter observes that geographic/jurisdictional considerations could affect profiles, for example the age of consent in different countries. This brings in the idea of how the Binding Obligations doc can be incorporated into a larger agreement or legal framework.
Which additional UMA token profiles are most needed next? (related to issues #14, #24, #50, #51)
See Eve's email discussing the landscape of options.
Today we do option 1 (specifically, 1a) according to Eve's earlier email. Does option 3 (giving claims to the host in the token) potentially expose the host inappropriately to user claims? Yes, particularly in the case where the requesting party isn't the authorizing party. That would have to be dealt with in the Binding Obligations, if it's even allowed at all. Some folks have already expressed interest in option 2 (giving just an authorization decision to the host in the token), so we should probably work on that one next.
As of 12 Jul 2012 (pre-meeting), quorum is 6 of 11.
Is this site useful to you? Please share it!
| | More
Pages in this Space: