...
- All-hands meeting on Thursday, Feb 28, at 9am PT (time chart)
- Skype: +99051000000481
- US: +1-805-309-2350 (other international dial-in lines available) | Room Code: 178-2540
Attendees
- Eve
- Domenico
- Andrew
- George
- Adrian
- Keith
- Nick
- Thomas
- Sal
Regrets:
- Maciej
Next Meetings
- All-hands meeting on Thursday, Feb 28, at 9am PT (time chart) – Thomas regrets
UMA telecon 2013-02-28
- Roll call (seeking quorum)
- Approval of past minutes
- Action item review
- Sketch elements needed for an "UMA-protected OpenID Connect", including discovery of claim types available through an AS
- AOB (send your suggestions)Voting participants
- Eve
- Alam
- Domenico
- Maciej
- Keith
- George
- Sal
Non-voting participants:
- Nat
...
Agenda
- Roll call
- Approval of past minutes
- Action item review
- Sketch elements needed for an "UMA-protected OpenID Connect", including discovery of claim types available through an AS
- AOB
Minutes
Roll call
Quorum was reached.
Approval of past minutes
MOTION: Keith moves: Approve minutes of UMA telecon 2013-01-31 and reading into today's minutes the following past focus meeting: UMA telecon 2013-02-21. APPROVED by unanimous consent.
Action item
...
review
Keith has begun meeting with Mike to understand Gluu better re its software tests.
Eve has learned that Gluu has pushed forward on extensibility of policy profiling.
Sketch elements needed for an "UMA-protected OpenID Connect", including discovery of claim types available through an AS
What would UMA-protected OpenID Connect look like? The goal would be to expand the possibilities for authorized sharing of identity claims (a subspecies of protected resource), so that you could have Alice-to-whoever sharing. E.g., Alice might want to share with Bob her health status after a particular medical test is done, without giving him her password etc. and without her having to be awake and logged in somewhere at the moment he tries to access the resource. UMA enables sharing with with RPs (relying parties) who aren't necessarily necessarily SPs (service providers) to the resource owner.
In the past, we've discussed this in the context of "true access-controlled sharing" – the requesting party doesn't have to be a user of the resource server, with an account there, to get access; they just have to qualify in according to the resource owner's policy. E.g., Alice could meaningfully restrict Flickr photo access to Bob even if he doesn't have a Flickr login. But this UMA-protected OIC use case is a bit different; it's the reciprocal. What we want to do is stand up UMA protection in front of the the AP (attribute provider).
For the Street Identity scenario, if we assume Google as the OP and Verizon as the putative AP, can we say that Google would be the UMA AS and Verizon would be the UMA RS? Normally the AP in OIC would be responsible for managing the release of claims, though OIC hasn't ?? really standardized AP-related flows. Would the AS now centrally take over? OIC says nothing about how you ask for or get authorized to have distributed or aggregated claims. The assumption has been that the RP gets the user to authorize access to some set of claims for which the user is the owner.
...
So if we can solve doing discovery of resource types (including identity claims), then that would get us pretty far. The UMA AS app developers can do a lot to facilitate "personal discovery" of a person's preferred photo service, etc.
Attendees
As of 27 Nov 2012, quorum is 6 of 10.
- Eve
- Alam
- Domenico
- Maciej
- Keith
- George
- Sal
Non-voting participants:
- Nat
Next Meetings
- Focus meeting on Thursday, Mar 7, at 9am PT (time chart)
- Focus meeting on Thursday, Mar 14, at 9am PT (time chart)
- Focus meeting on Thursday, Mar 21, at 9am PT (time chart)
- All-hands meeting on Thursday, Mar 21, at 9am PT (time chart)