Notes from UMA telecon 2016-02-04
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-04 MinutesRoll call Quorum was not reaching. Approve minutes Deferred. Force-rank use cases What's A and what's B in terms of priority (since we probably can't get more "rank-y" than that)? John W suggests working from "likelihood of error occurring" and "impact of the error". The other factor is "detectability of the error". If the exploit is 100% undetectable, that's bad. This is a good way to prioritize #security work (which is overtly about bugs). For feature work prioritization, we had talked about gathering "customer need" in 2016 or 2017. Mike adds that this could include "developer adoption" – so are we targeting developers and deployers both? "Customers" would typically mean those who know they need UMA. "Developer adoption" is about building community among those who may not know they "need UMA" yet. (This is what Adrian's goal is around an always-on AS, to entice RS and client developers.) George questions that UMA should be looking for adoption in the OAuth fashion. How do we define #wideeco? If we correctly define mechanisms for dynamic onboarding of disparate parties, wouldn't it be the case that the narrower ecosystems would tend to use those mechanisms to build their deployments? The question is whether dynamic mechanisms add too much overhead for static partnerships to be willing to use. So maybe it's not just about correct definition of mechanisms; it's about a continuum of needs. There's definitely a tension present around when to optimize for #wideeco, and what our options are. It's not just about how to gather claims securely from Bob when his claims providers and Alice's AS-as-a-claims-client have not pre-established trust between them. There are other considerations as well, as we look at the broader implications of what "value-add features" are desired. AI: Eve and James: Share technical paper/thoughts on potential solutions to "Bob when his claims providers and Alice's AS-as-a-claims-client have not pre-established trust between them" So far – all still being discussed: #IoT (Eve), #APIsec, #fedauthz, #RSctrl, #ROctrl, #wideeco (Adrian, Justin), #trust, #security (Justin, Eve) Justin adds a vote for the issues he submitted that have to do with implementation simplification and, in some cases, making it an OAuth extension grant (?). This needs a new "hashtag". *AI:* Eve: Add a #simplification label and add the self-contained token discussion to that issue. John W notes that constraining sharing based on geolocation would be a good idea. Eve suggests adding an issue on this. *AI:* Eve: Set up one more round of ad hoc #239 meetings next week, in hopes of finishing then. Validation of self-contained token discussion on that back channel: - Mike Schwartz@All: I don't think self-contained tokens is limited to IOT... - Mike Schwartz@All: And also, I'm not sure its possilble... - Justin Richer@All: Self contained tokens are in no way limited to IoT and that's not hte only issue of IoT. And how is it not possible? People have been doing it for many, many years. - George Fletcher@All: agreed that self-contained tokens are limited to IoT. I also think that while we should use JWT for the token syntax there are some real issues to solve here. - Mike Schwartz@All: of course self contained tokens are possible, but the way we defined the RPT flow - Mike Schwartz@All: the RPT gets issued, and its empty - Mike Schwartz@All: and then permissions get added. - Mike Schwartz@All: So its not that RPT can't be self-contained, but it can't be used as an access token - Mike Schwartz@All: because the access token value would change - Justin Richer@All: That's not how we issue RPTs. We don't issue RPTs until there are permissions to it. If we add permissions we'd issue a new RPT which is valid. - George Fletcher@All: Yes, or become a "super" token which has it's own security issues. - Justin Richer@All: Right, super tokens are a big problem in wider cases. Charter revision Deferred. Use case work See the issue #239 meeting series email thread for the continuing notes on that. Attendees As of 20 Jan 2016, quorum is 7 of 12. (Evariste, François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike) 1. Eve 2. Mike 3. Kathleen 4. Andi Non-voting participants: - Justin - John W - George - Adrian - Sarah - Jin *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
I'd like to add my vote to the #wideeco effort. I believe it's better to solve for the final problem and then optimize the medium and narrow cases rather than add features for the narrow and medium cases that could preclude the #wideeco effort from ever being viable. Of course, as a work group we could decide that we don't ever want to solve the #wideeco problem and in that case there is no need to worry about how current decisions could impact that in the future. However, if we want to solve the #wideeco problem, then I believe we need to tackle it sooner rather than later. This of course does not preclude existing deployments for narrow and medium use cases making assumptions and removing complexity. We can take OpenID Connect as an example. It's possible to do discovery and dynamic client registration, but most deployments don't have those needs and so the clients don't support discovery or dynamic client reg and instead just have the endpoints statically configured. I'd like to see UMA take a similar approach; meaning tackle the issues and compose the specs as makes sense for a range of deployments. Thanks, George On 2/4/16 1:29 PM, Eve Maler wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-04
Minutes
Roll call
Quorum was not reaching.
Approve minutes
Deferred.
Force-rank use cases
What's A and what's B in terms of priority (since we probably can't get more "rank-y" than that)? John W suggests working from "likelihood of error occurring" and "impact of the error". The other factor is "detectability of the error". If the exploit is 100% undetectable, that's bad. This is a good way to prioritize #security work (which is overtly about bugs). For feature work prioritization, we had talked about gathering "customer need" in 2016 or 2017. Mike adds that this could include "developer adoption" – so are we targeting developers and deployers both? "Customers" would typically mean those who know they need UMA. "Developer adoption" is about building community among those who may not know they "need UMA" yet. (This is what Adrian's goal is around an always-on AS, to entice RS and client developers.) George questions that UMA should be looking for adoption in the OAuth fashion.
How do we define #wideeco? If we correctly define mechanisms for dynamic onboarding of disparate parties, wouldn't it be the case that the narrower ecosystems would tend to use those mechanisms to build their deployments? The question is whether dynamic mechanisms add too much overhead for static partnerships to be willing to use. So maybe it's not just about correct definition of mechanisms; it's about a continuum of needs. There's definitely a tension present around when to optimize for #wideeco, and what our options are. It's not just about how to gather claims securely from Bob when his claims providers and Alice's AS-as-a-claims-client have not pre-established trust between them. There are other considerations as well, as we look at the broader implications of what "value-add features" are desired.
AI: Eve and James: Share technical paper/thoughts on potential solutions to "Bob when his claims providers and Alice's AS-as-a-claims-client have not pre-established trust between them"
So far – all still being discussed:
#IoT (Eve), #APIsec, #fedauthz, #RSctrl, #ROctrl, #wideeco (Adrian, Justin), #trust, #security (Justin, Eve)
Justin adds a vote for the issues he submitted that have to do with implementation simplification and, in some cases, making it an OAuth extension grant (?). This needs a new "hashtag".
*AI:* Eve: Add a #simplification label and add the self-contained token discussion to that issue.
John W notes that constraining sharing based on geolocation would be a good idea. Eve suggests adding an issue on this.
*AI:* Eve: Set up one more round of ad hoc #239 meetings next week, in hopes of finishing then.
Validation of self-contained token discussion on that back channel:
* Mike Schwartz@All: I don't think self-contained tokens is limited to IOT... * Mike Schwartz@All: And also, I'm not sure its possilble... * Justin Richer@All: Self contained tokens are in no way limited to IoT and that's not hte only issue of IoT. And how is it not possible? People have been doing it for many, many years. * George Fletcher@All: agreed that self-contained tokens are limited to IoT. I also think that while we should use JWT for the token syntax there are some real issues to solve here. * Mike Schwartz@All: of course self contained tokens are possible, but the way we defined the RPT flow * Mike Schwartz@All: the RPT gets issued, and its empty * Mike Schwartz@All: and then permissions get added. * Mike Schwartz@All: So its not that RPT can't be self-contained, but it can't be used as an access token * Mike Schwartz@All: because the access token value would change * Justin Richer@All: That's not how we issue RPTs. We don't issue RPTs until there are permissions to it. If we add permissions we'd issue a new RPT which is valid. * George Fletcher@All: Yes, or become a "super" token which has it's own security issues. * Justin Richer@All: Right, super tokens are a big problem in wider cases.
Charter revision
Deferred.
Use case work
See the issue #239 meeting series email thread for the continuing notes on that.
Attendees
As of 20 Jan 2016, quorum is 7 of 12. (Evariste, François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike)
1. Eve 2. Mike 3. Kathleen 4. Andi
Non-voting participants:
* Justin * John W * George * Adrian * Sarah * Jin
*Eve Maler *Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- Chief Architect Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography
#IoT is also a #wideeco use case.
As trusted execution environments become available in $1 chips
http://ragingbull.com/forum/topic/1044322, there will be only two kinds
of connected Things, those with a user interface and those without. The
current model of every device going first to a vendor's cloud and then back
to the owner is unsustainable from a privacy, reliability, and scalability
perspective.
With or without a user interface, these Things will connect first to local
hubs and apps and only then, occasionally, they will connect to corporate
clouds. UMA can position itself to provide user-owned authorization
services for Things with trusted execution environments. This will
certainly be a #wideeco use-case.
Adrian
On Thu, Feb 4, 2016 at 4:19 PM, George Fletcher wrote: I'd like to add my vote to the #wideeco effort. I believe it's better to solve for the final problem and then optimize the
medium and narrow cases rather than add features for the narrow and medium
cases that could preclude the #wideeco effort from ever being viable. Of course, as a work group we could decide that we don't ever want to
solve the #wideeco problem and in that case there is no need to worry about
how current decisions could impact that in the future. However, if we want
to solve the #wideeco problem, then I believe we need to tackle it sooner
rather than later. This of course does not preclude existing deployments for narrow and
medium use cases making assumptions and removing complexity. We can take
OpenID Connect as an example. It's possible to do discovery and dynamic
client registration, but most deployments don't have those needs and so the
clients don't support discovery or dynamic client reg and instead just have
the endpoints statically configured. I'd like to see UMA take a similar approach; meaning tackle the issues and
compose the specs as makes sense for a range of deployments. Thanks,
George On 2/4/16 1:29 PM, Eve Maler wrote: http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-04
Minutes Roll call Quorum was not reaching.
Approve minutes Deferred.
Force-rank use cases What's A and what's B in terms of priority (since we probably can't get
more "rank-y" than that)? John W suggests working from "likelihood of error
occurring" and "impact of the error". The other factor is "detectability of
the error". If the exploit is 100% undetectable, that's bad. This is a good
way to prioritize #security work (which is overtly about bugs). For feature
work prioritization, we had talked about gathering "customer need" in 2016
or 2017. Mike adds that this could include "developer adoption" – so are we
targeting developers and deployers both? "Customers" would typically mean
those who know they need UMA. "Developer adoption" is about building
community among those who may not know they "need UMA" yet. (This is what
Adrian's goal is around an always-on AS, to entice RS and client
developers.) George questions that UMA should be looking for adoption in
the OAuth fashion. How do we define #wideeco? If we correctly define mechanisms for dynamic
onboarding of disparate parties, wouldn't it be the case that the narrower
ecosystems would tend to use those mechanisms to build their deployments?
The question is whether dynamic mechanisms add too much overhead for static
partnerships to be willing to use. So maybe it's not just about correct
definition of mechanisms; it's about a continuum of needs. There's
definitely a tension present around when to optimize for #wideeco, and what
our options are. It's not just about how to gather claims securely from Bob
when his claims providers and Alice's AS-as-a-claims-client have not
pre-established trust between them. There are other considerations as well,
as we look at the broader implications of what "value-add features" are
desired. AI: Eve and James: Share technical paper/thoughts on potential solutions
to "Bob when his claims providers and Alice's AS-as-a-claims-client have
not pre-established trust between them" So far – all still being discussed: #IoT (Eve), #APIsec, #fedauthz, #RSctrl, #ROctrl, #wideeco (Adrian,
Justin), #trust, #security (Justin, Eve) Justin adds a vote for the issues he submitted that have to do with
implementation simplification and, in some cases, making it an OAuth
extension grant (?). This needs a new "hashtag". *AI:* Eve: Add a #simplification label and add the self-contained token
discussion to that issue. John W notes that constraining sharing based on geolocation would be a
good idea. Eve suggests adding an issue on this. *AI:* Eve: Set up one more round of ad hoc #239 meetings next week, in
hopes of finishing then. Validation of self-contained token discussion on that back channel: - Mike Schwartz@All: I don't think self-contained tokens is limited to
IOT...
- Mike Schwartz@All: And also, I'm not sure its possilble...
- Justin Richer@All: Self contained tokens are in no way limited to
IoT and that's not hte only issue of IoT. And how is it not possible?
People have been doing it for many, many years.
- George Fletcher@All: agreed that self-contained tokens are limited
to IoT. I also think that while we should use JWT for the token syntax
there are some real issues to solve here.
- Mike Schwartz@All: of course self contained tokens are possible, but
the way we defined the RPT flow
- Mike Schwartz@All: the RPT gets issued, and its empty
- Mike Schwartz@All: and then permissions get added.
- Mike Schwartz@All: So its not that RPT can't be self-contained, but
it can't be used as an access token
- Mike Schwartz@All: because the access token value would change
- Justin Richer@All: That's not how we issue RPTs. We don't issue RPTs
until there are permissions to it. If we add permissions we'd issue a new
RPT which is valid.
- George Fletcher@All: Yes, or become a "super" token which has it's
own security issues.
- Justin Richer@All: Right, super tokens are a big problem in wider
cases. Charter revision Deferred.
Use case work See the issue #239 meeting series email thread for the continuing notes on
that.
Attendees As of 20 Jan 2016, quorum is 7 of 12. (Evariste, François, Domenico,
Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike) 1. Eve
2. Mike
3. Kathleen
4. Andi Non-voting participants: - Justin
- John W
- George
- Adrian
- Sarah
- Jin *Eve Maler *Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl _______________________________________________
WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma --
Chief Architect
Identity Services Engineering Work: george.fletcher@teamaol.com
AOL Inc. AIM: gffletch
Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544 Photos: http://georgefletcher.photography _______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma --
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
+1 on George's prioritisation suggestion & logic
+1 on #IoT being a #wideeco use-case.
--&e
On Fri, Feb 5, 2016 at 3:42 AM, Adrian Gropper
#IoT is also a #wideeco use case.
As trusted execution environments become available in $1 chips http://ragingbull.com/forum/topic/1044322, there will be only two kinds of connected Things, those with a user interface and those without. The current model of every device going first to a vendor's cloud and then back to the owner is unsustainable from a privacy, reliability, and scalability perspective.
With or without a user interface, these Things will connect first to local hubs and apps and only then, occasionally, they will connect to corporate clouds. UMA can position itself to provide user-owned authorization services for Things with trusted execution environments. This will certainly be a #wideeco use-case.
Adrian
On Thu, Feb 4, 2016 at 4:19 PM, George Fletcher < george.fletcher@teamaol.com> wrote:
I'd like to add my vote to the #wideeco effort.
I believe it's better to solve for the final problem and then optimize the medium and narrow cases rather than add features for the narrow and medium cases that could preclude the #wideeco effort from ever being viable.
Of course, as a work group we could decide that we don't ever want to solve the #wideeco problem and in that case there is no need to worry about how current decisions could impact that in the future. However, if we want to solve the #wideeco problem, then I believe we need to tackle it sooner rather than later.
This of course does not preclude existing deployments for narrow and medium use cases making assumptions and removing complexity. We can take OpenID Connect as an example. It's possible to do discovery and dynamic client registration, but most deployments don't have those needs and so the clients don't support discovery or dynamic client reg and instead just have the endpoints statically configured.
I'd like to see UMA take a similar approach; meaning tackle the issues and compose the specs as makes sense for a range of deployments.
Thanks, George
On 2/4/16 1:29 PM, Eve Maler wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-04 Minutes Roll call
Quorum was not reaching. Approve minutes
Deferred. Force-rank use cases
What's A and what's B in terms of priority (since we probably can't get more "rank-y" than that)? John W suggests working from "likelihood of error occurring" and "impact of the error". The other factor is "detectability of the error". If the exploit is 100% undetectable, that's bad. This is a good way to prioritize #security work (which is overtly about bugs). For feature work prioritization, we had talked about gathering "customer need" in 2016 or 2017. Mike adds that this could include "developer adoption" – so are we targeting developers and deployers both? "Customers" would typically mean those who know they need UMA. "Developer adoption" is about building community among those who may not know they "need UMA" yet. (This is what Adrian's goal is around an always-on AS, to entice RS and client developers.) George questions that UMA should be looking for adoption in the OAuth fashion.
How do we define #wideeco? If we correctly define mechanisms for dynamic onboarding of disparate parties, wouldn't it be the case that the narrower ecosystems would tend to use those mechanisms to build their deployments? The question is whether dynamic mechanisms add too much overhead for static partnerships to be willing to use. So maybe it's not just about correct definition of mechanisms; it's about a continuum of needs. There's definitely a tension present around when to optimize for #wideeco, and what our options are. It's not just about how to gather claims securely from Bob when his claims providers and Alice's AS-as-a-claims-client have not pre-established trust between them. There are other considerations as well, as we look at the broader implications of what "value-add features" are desired.
AI: Eve and James: Share technical paper/thoughts on potential solutions to "Bob when his claims providers and Alice's AS-as-a-claims-client have not pre-established trust between them"
So far – all still being discussed:
#IoT (Eve), #APIsec, #fedauthz, #RSctrl, #ROctrl, #wideeco (Adrian, Justin), #trust, #security (Justin, Eve)
Justin adds a vote for the issues he submitted that have to do with implementation simplification and, in some cases, making it an OAuth extension grant (?). This needs a new "hashtag".
*AI:* Eve: Add a #simplification label and add the self-contained token discussion to that issue.
John W notes that constraining sharing based on geolocation would be a good idea. Eve suggests adding an issue on this.
*AI:* Eve: Set up one more round of ad hoc #239 meetings next week, in hopes of finishing then.
Validation of self-contained token discussion on that back channel:
- Mike Schwartz@All: I don't think self-contained tokens is limited to IOT... - Mike Schwartz@All: And also, I'm not sure its possilble... - Justin Richer@All: Self contained tokens are in no way limited to IoT and that's not hte only issue of IoT. And how is it not possible? People have been doing it for many, many years. - George Fletcher@All: agreed that self-contained tokens are limited to IoT. I also think that while we should use JWT for the token syntax there are some real issues to solve here. - Mike Schwartz@All: of course self contained tokens are possible, but the way we defined the RPT flow - Mike Schwartz@All: the RPT gets issued, and its empty - Mike Schwartz@All: and then permissions get added. - Mike Schwartz@All: So its not that RPT can't be self-contained, but it can't be used as an access token - Mike Schwartz@All: because the access token value would change - Justin Richer@All: That's not how we issue RPTs. We don't issue RPTs until there are permissions to it. If we add permissions we'd issue a new RPT which is valid. - George Fletcher@All: Yes, or become a "super" token which has it's own security issues. - Justin Richer@All: Right, super tokens are a big problem in wider cases.
Charter revision
Deferred. Use case work
See the issue #239 meeting series email thread for the continuing notes on that. Attendees
As of 20 Jan 2016, quorum is 7 of 12. (Evariste, François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike)
1. Eve 2. Mike 3. Kathleen 4. Andi
Non-voting participants:
- Justin - John W - George - Adrian - Sarah - Jin
*Eve Maler *Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma
-- Chief Architect Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- Andrew Hindle Hindle Consulting Limited +44 7966 136543 -- ------------------------------ Hindle Consulting Limited is a company registered in England and Wales. Company number: 8888564. Registered office: Claremont House, Deans Court, Bicester, Oxfordshire OX26 6BW, UK.
I honestly can't understand how UMA can thrive without the #wideeco as a
foundation. The venn on our home page tells the story. The place where
reputation and federated trust matters is in the IdP circle. The place
where an individual can own and fully control an agent is UMA. [image: The
new Venn of access control and consent Copyright © Identity Summit 2015,
all rights reserved.]
I'm very sorry to see this image is gone from our home page.
The UMA Authorization Server is unique. It is the _only_ technology that an
individual user can own and completely control. As such, it almost defines
privacy in the digital age. That doesn't mean that individuals can't choose
to outsource the AS functionality to institutions or even to brokers, but
that has to remain a choice at the very core of the UMA foundation.
Forcing the federations and institutions to respect a fully owned
authorization server will be liberating. Anything less will simply confuse
potential adopters as they seek to understand why not profile OIDC or OAuth
to meet their need.
Adrian
On Fri, Feb 5, 2016 at 5:46 AM, Andrew Hindle
+1 on George's prioritisation suggestion & logic +1 on #IoT being a #wideeco use-case.
--&e
On Fri, Feb 5, 2016 at 3:42 AM, Adrian Gropper
wrote: #IoT is also a #wideeco use case.
As trusted execution environments become available in $1 chips http://ragingbull.com/forum/topic/1044322, there will be only two kinds of connected Things, those with a user interface and those without. The current model of every device going first to a vendor's cloud and then back to the owner is unsustainable from a privacy, reliability, and scalability perspective.
With or without a user interface, these Things will connect first to local hubs and apps and only then, occasionally, they will connect to corporate clouds. UMA can position itself to provide user-owned authorization services for Things with trusted execution environments. This will certainly be a #wideeco use-case.
Adrian
On Thu, Feb 4, 2016 at 4:19 PM, George Fletcher < george.fletcher@teamaol.com> wrote:
I'd like to add my vote to the #wideeco effort.
I believe it's better to solve for the final problem and then optimize the medium and narrow cases rather than add features for the narrow and medium cases that could preclude the #wideeco effort from ever being viable.
Of course, as a work group we could decide that we don't ever want to solve the #wideeco problem and in that case there is no need to worry about how current decisions could impact that in the future. However, if we want to solve the #wideeco problem, then I believe we need to tackle it sooner rather than later.
This of course does not preclude existing deployments for narrow and medium use cases making assumptions and removing complexity. We can take OpenID Connect as an example. It's possible to do discovery and dynamic client registration, but most deployments don't have those needs and so the clients don't support discovery or dynamic client reg and instead just have the endpoints statically configured.
I'd like to see UMA take a similar approach; meaning tackle the issues and compose the specs as makes sense for a range of deployments.
Thanks, George
On 2/4/16 1:29 PM, Eve Maler wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-04 Minutes Roll call
Quorum was not reaching. Approve minutes
Deferred. Force-rank use cases
What's A and what's B in terms of priority (since we probably can't get more "rank-y" than that)? John W suggests working from "likelihood of error occurring" and "impact of the error". The other factor is "detectability of the error". If the exploit is 100% undetectable, that's bad. This is a good way to prioritize #security work (which is overtly about bugs). For feature work prioritization, we had talked about gathering "customer need" in 2016 or 2017. Mike adds that this could include "developer adoption" – so are we targeting developers and deployers both? "Customers" would typically mean those who know they need UMA. "Developer adoption" is about building community among those who may not know they "need UMA" yet. (This is what Adrian's goal is around an always-on AS, to entice RS and client developers.) George questions that UMA should be looking for adoption in the OAuth fashion.
How do we define #wideeco? If we correctly define mechanisms for dynamic onboarding of disparate parties, wouldn't it be the case that the narrower ecosystems would tend to use those mechanisms to build their deployments? The question is whether dynamic mechanisms add too much overhead for static partnerships to be willing to use. So maybe it's not just about correct definition of mechanisms; it's about a continuum of needs. There's definitely a tension present around when to optimize for #wideeco, and what our options are. It's not just about how to gather claims securely from Bob when his claims providers and Alice's AS-as-a-claims-client have not pre-established trust between them. There are other considerations as well, as we look at the broader implications of what "value-add features" are desired.
AI: Eve and James: Share technical paper/thoughts on potential solutions to "Bob when his claims providers and Alice's AS-as-a-claims-client have not pre-established trust between them"
So far – all still being discussed:
#IoT (Eve), #APIsec, #fedauthz, #RSctrl, #ROctrl, #wideeco (Adrian, Justin), #trust, #security (Justin, Eve)
Justin adds a vote for the issues he submitted that have to do with implementation simplification and, in some cases, making it an OAuth extension grant (?). This needs a new "hashtag".
*AI:* Eve: Add a #simplification label and add the self-contained token discussion to that issue.
John W notes that constraining sharing based on geolocation would be a good idea. Eve suggests adding an issue on this.
*AI:* Eve: Set up one more round of ad hoc #239 meetings next week, in hopes of finishing then.
Validation of self-contained token discussion on that back channel:
- Mike Schwartz@All: I don't think self-contained tokens is limited to IOT... - Mike Schwartz@All: And also, I'm not sure its possilble... - Justin Richer@All: Self contained tokens are in no way limited to IoT and that's not hte only issue of IoT. And how is it not possible? People have been doing it for many, many years. - George Fletcher@All: agreed that self-contained tokens are limited to IoT. I also think that while we should use JWT for the token syntax there are some real issues to solve here. - Mike Schwartz@All: of course self contained tokens are possible, but the way we defined the RPT flow - Mike Schwartz@All: the RPT gets issued, and its empty - Mike Schwartz@All: and then permissions get added. - Mike Schwartz@All: So its not that RPT can't be self-contained, but it can't be used as an access token - Mike Schwartz@All: because the access token value would change - Justin Richer@All: That's not how we issue RPTs. We don't issue RPTs until there are permissions to it. If we add permissions we'd issue a new RPT which is valid. - George Fletcher@All: Yes, or become a "super" token which has it's own security issues. - Justin Richer@All: Right, super tokens are a big problem in wider cases.
Charter revision
Deferred. Use case work
See the issue #239 meeting series email thread for the continuing notes on that. Attendees
As of 20 Jan 2016, quorum is 7 of 12. (Evariste, François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike)
1. Eve 2. Mike 3. Kathleen 4. Andi
Non-voting participants:
- Justin - John W - George - Adrian - Sarah - Jin
*Eve Maler *Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma
-- Chief Architect Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- Andrew Hindle Hindle Consulting Limited +44 7966 136543
------------------------------ Hindle Consulting Limited is a company registered in England and Wales. Company number: 8888564. Registered office: Claremont House, Deans Court, Bicester, Oxfordshire OX26 6BW, UK.
-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
participants (4)
-
Adrian Gropper
-
Andrew Hindle
-
Eve Maler
-
George Fletcher