Draft minutes of UMA telecon 2016-02-18
Great meeting, all! http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 MinutesRoll call Quorum was reached. Approve minutes Minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> approved. Issue #239 - *Proposal:* Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already) Proposal accepted. - *Proposal:* Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension Sal and Eve just discussed in email whether a stronger authentication mitigation would work. Session fixation happens after victim authentication, so it wouldn't help. Robert mentioned to Eve offline that Wikipedia has some comments on session fixation that might be useful. Eve believes that since the permission ticket gets passed in UMA JSON messages, the countermeasures there may not apply, but we could look (for purposes of the non-normative analysis if ultimately nothing else). - *For discussion:* Consider also handling issue #167 in this extension if it has a security rationale If the AS uses the flexibility to give a new endpoint, then there's the danger of giving an attacker new information outside of the discovery document that it didn't have before, which is a degradation of security. If the AS doesn't avail itself of the flexibility, then it doesn't seem to add anything. In any case, we're not thinking of a security rationale for adding this feature to the extension. In any case, it sounds like taking up #167 as part of the extension work doesn't meet our "#security use case bucket" goals, so we'll defer that till such time as we take up "#simplify use case bucket" work. *Consensus:* We want to write and publish the extension specification. - *For discussion* (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG - *For discussion* (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue) The WG itself can self-approve a technical specification, and the LC can approve that group output. (Are these "WG Reports"? Eve will check with the LC.) In other words, this could remain at a level sort of equivalent to an IETF I-D and not progress to an "RFC" level before it eventually gets absorbed into a later version of the UMA Core spec. We do want to recommend that everyone using the claims-gathering endpoint use this approach, but it all depends on the timing of any new UMA "V.next" version. We basically need to defer the decision about its "track" until we execute on the rest of our roadmap. *AI:* Eve, Domenico, Maciej: Write the extension spec. Can we publish these by next Thursday? Let's give the old college try. We want to publish and publicize the draft docs at the same time. Wide ecosystem challenges Eve presented a set of high-level statements that describe the dual nature of the challenges. Eve/James and Maciej will share some material on the challenges. John observes that it's an ouroboros – a snake eating its own tail (or as Eve likes to call it, the bubble under the wallpaper that you can move but you can't remove). Some discussion arose about different solutions, e.g.: - UMA-protected user claims endpoint ("UserInfo") - Agreed-on central authority (e.g. hospital) serving as a claims endpoint/AS (?) – akin to the question that has arisen over the last decade-plus about "who's the IdP" The group agreed to collect all the potential solutions "without fear or favor" and then analyzes how well they solve the challenges. Attendees As of 16 Feb 2016, quorum is 6 of 10. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike) 1. Eve 2. Kathleen 3. François 4. Domenico 5. Sal 6. Mike 7. Maciej Non-voting participants: - John W - Sarah - Adrian - George - Scott - Mark - *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
I would characterize the hospital as a context specific authority, not a central authority. At least that’s how I heard Adrian’s remarks, and is how I think of financial institutions. The central authority that was mentioned was the equivalent of the central DNS servers or CA’s for SSL, and that’s a whole different world of pain. Sincerely, John Wunderlich (@PrivacyCDN) <http://privacybydesign.ca/> <http://privacybydesign.ca/> <http://privacybydesign.ca/>Privacist & PbD Ambassador <http://privacybydesign.ca/>
On Feb 18, 2016, at 13:09, Eve Maler <eve@xmlgrrl.com> wrote:
Great meeting, all!
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18> Minutes Roll call Quorum was reached. Approve minutes Minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> approved. Issue #239 Proposal: Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already) Proposal accepted. Proposal: Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension Sal and Eve just discussed in email whether a stronger authentication mitigation would work. Session fixation happens after victim authentication, so it wouldn't help. Robert mentioned to Eve offline that Wikipedia has some comments on session fixation that might be useful. Eve believes that since the permission ticket gets passed in UMA JSON messages, the countermeasures there may not apply, but we could look (for purposes of the non-normative analysis if ultimately nothing else). For discussion: Consider also handling issue #167 in this extension if it has a security rationale If the AS uses the flexibility to give a new endpoint, then there's the danger of giving an attacker new information outside of the discovery document that it didn't have before, which is a degradation of security. If the AS doesn't avail itself of the flexibility, then it doesn't seem to add anything. In any case, we're not thinking of a security rationale for adding this feature to the extension. In any case, it sounds like taking up #167 as part of the extension work doesn't meet our "#security use case bucket" goals, so we'll defer that till such time as we take up "#simplify use case bucket" work. Consensus: We want to write and publish the extension specification. For discussion (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG For discussion (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue) The WG itself can self-approve a technical specification, and the LC can approve that group output. (Are these "WG Reports"? Eve will check with the LC.) In other words, this could remain at a level sort of equivalent to an IETF I-D and not progress to an "RFC" level before it eventually gets absorbed into a later version of the UMA Core spec. We do want to recommend that everyone using the claims-gathering endpoint use this approach, but it all depends on the timing of any new UMA "V.next" version. We basically need to defer the decision about its "track" until we execute on the rest of our roadmap. AI: Eve, Domenico, Maciej: Write the extension spec. Can we publish these by next Thursday? Let's give the old college try. We want to publish and publicize the draft docs at the same time. Wide ecosystem challenges Eve presented a set of high-level statements that describe the dual nature of the challenges. Eve/James and Maciej will share some material on the challenges. John observes that it's an ouroboros – a snake eating its own tail (or as Eve likes to call it, the bubble under the wallpaper that you can move but you can't remove). Some discussion arose about different solutions, e.g.: UMA-protected user claims endpoint ("UserInfo") Agreed-on central authority (e.g. hospital) serving as a claims endpoint/AS (?) – akin to the question that has arisen over the last decade-plus about "who's the IdP" The group agreed to collect all the potential solutions "without fear or favor" and then analyzes how well they solve the challenges. Attendees As of 16 Feb 2016, quorum is 6 of 10. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike) Eve Kathleen François Domenico Sal Mike Maciej Non-voting participants: John W Sarah Adrian George Scott Mark
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
-- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
"Central" is merely a contextual term in any case, probably. I certainly wouldn't have meant it as "central" in a DNS sense. (That would mean that I would have liked Microsoft Passport circa 2001. :-) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Feb 18, 2016 at 11:00 AM, John Wunderlich <john@wunderlich.ca> wrote:
I would characterize the hospital as a context specific authority, not a central authority. At least that’s how I heard Adrian’s remarks, and is how I think of financial institutions. The central authority that was mentioned was the equivalent of the central DNS servers or CA’s for SSL, and that’s a whole different world of pain.
Sincerely, *John Wunderlich* *(@PrivacyCDN)*
<http://privacybydesign.ca> <http://privacybydesign.ca>
<http://privacybydesign.ca>Privacist & PbD Ambassador <http://privacybydesign.ca>
On Feb 18, 2016, at 13:09, Eve Maler <eve@xmlgrrl.com> wrote:
Great meeting, all!
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 MinutesRoll call
Quorum was reached. Approve minutes
Minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> approved. Issue #239
- *Proposal:* Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already)
Proposal accepted.
- *Proposal:* Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension
Sal and Eve just discussed in email whether a stronger authentication mitigation would work. Session fixation happens after victim authentication, so it wouldn't help.
Robert mentioned to Eve offline that Wikipedia has some comments on session fixation that might be useful. Eve believes that since the permission ticket gets passed in UMA JSON messages, the countermeasures there may not apply, but we could look (for purposes of the non-normative analysis if ultimately nothing else).
- *For discussion:* Consider also handling issue #167 in this extension if it has a security rationale
If the AS uses the flexibility to give a new endpoint, then there's the danger of giving an attacker new information outside of the discovery document that it didn't have before, which is a degradation of security. If the AS doesn't avail itself of the flexibility, then it doesn't seem to add anything. In any case, we're not thinking of a security rationale for adding this feature to the extension. In any case, it sounds like taking up #167 as part of the extension work doesn't meet our "#security use case bucket" goals, so we'll defer that till such time as we take up "#simplify use case bucket" work.
*Consensus:* We want to write and publish the extension specification.
- *For discussion* (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG - *For discussion* (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue)
The WG itself can self-approve a technical specification, and the LC can approve that group output. (Are these "WG Reports"? Eve will check with the LC.) In other words, this could remain at a level sort of equivalent to an IETF I-D and not progress to an "RFC" level before it eventually gets absorbed into a later version of the UMA Core spec. We do want to recommend that everyone using the claims-gathering endpoint use this approach, but it all depends on the timing of any new UMA "V.next" version. We basically need to defer the decision about its "track" until we execute on the rest of our roadmap.
*AI:* Eve, Domenico, Maciej: Write the extension spec.
Can we publish these by next Thursday? Let's give the old college try. We want to publish and publicize the draft docs at the same time. Wide ecosystem challenges
Eve presented a set of high-level statements that describe the dual nature of the challenges. Eve/James and Maciej will share some material on the challenges.
John observes that it's an ouroboros – a snake eating its own tail (or as Eve likes to call it, the bubble under the wallpaper that you can move but you can't remove).
Some discussion arose about different solutions, e.g.:
- UMA-protected user claims endpoint ("UserInfo") - Agreed-on central authority (e.g. hospital) serving as a claims endpoint/AS (?) – akin to the question that has arisen over the last decade-plus about "who's the IdP"
The group agreed to collect all the potential solutions "without fear or favor" and then analyzes how well they solve the challenges. Attendees
As of 16 Feb 2016, quorum is 6 of 10. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike)
1. Eve 2. Kathleen 3. François 4. Domenico 5. Sal 6. Mike 7. Maciej
Non-voting participants:
- John W - Sarah - Adrian - George - Scott - Mark -
*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
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
I know that it can be read that way, and I wasn’t a big fan of Passport either. That being said, perception is reality here and you might want to qualify what you mean be central when you use the word in the future. Just sayin' Sincerely, John Wunderlich (@PrivacyCDN) <http://privacybydesign.ca/> <http://privacybydesign.ca/> <http://privacybydesign.ca/>Privacist & PbD Ambassador <http://privacybydesign.ca/>
On Feb 18, 2016, at 19:42, Eve Maler <eve@xmlgrrl.com> wrote:
"Central" is merely a contextual term in any case, probably. I certainly wouldn't have meant it as "central" in a DNS sense. (That would mean that I would have liked Microsoft Passport circa 2001. :-)
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Feb 18, 2016 at 11:00 AM, John Wunderlich <john@wunderlich.ca <mailto:john@wunderlich.ca>> wrote: I would characterize the hospital as a context specific authority, not a central authority. At least that’s how I heard Adrian’s remarks, and is how I think of financial institutions. The central authority that was mentioned was the equivalent of the central DNS servers or CA’s for SSL, and that’s a whole different world of pain.
Sincerely, John Wunderlich (@PrivacyCDN)
<PastedGraphic-4.tiff> <http://privacybydesign.ca/> <http://privacybydesign.ca/>
<http://privacybydesign.ca/>Privacist & PbD Ambassador <http://privacybydesign.ca/>
On Feb 18, 2016, at 13:09, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
Great meeting, all!
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18> Minutes Roll call Quorum was reached. Approve minutes Minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> approved. Issue #239 Proposal: Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already) Proposal accepted. Proposal: Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension Sal and Eve just discussed in email whether a stronger authentication mitigation would work. Session fixation happens after victim authentication, so it wouldn't help. Robert mentioned to Eve offline that Wikipedia has some comments on session fixation that might be useful. Eve believes that since the permission ticket gets passed in UMA JSON messages, the countermeasures there may not apply, but we could look (for purposes of the non-normative analysis if ultimately nothing else). For discussion: Consider also handling issue #167 in this extension if it has a security rationale If the AS uses the flexibility to give a new endpoint, then there's the danger of giving an attacker new information outside of the discovery document that it didn't have before, which is a degradation of security. If the AS doesn't avail itself of the flexibility, then it doesn't seem to add anything. In any case, we're not thinking of a security rationale for adding this feature to the extension. In any case, it sounds like taking up #167 as part of the extension work doesn't meet our "#security use case bucket" goals, so we'll defer that till such time as we take up "#simplify use case bucket" work. Consensus: We want to write and publish the extension specification. For discussion (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG For discussion (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue) The WG itself can self-approve a technical specification, and the LC can approve that group output. (Are these "WG Reports"? Eve will check with the LC.) In other words, this could remain at a level sort of equivalent to an IETF I-D and not progress to an "RFC" level before it eventually gets absorbed into a later version of the UMA Core spec. We do want to recommend that everyone using the claims-gathering endpoint use this approach, but it all depends on the timing of any new UMA "V.next" version. We basically need to defer the decision about its "track" until we execute on the rest of our roadmap. AI: Eve, Domenico, Maciej: Write the extension spec. Can we publish these by next Thursday? Let's give the old college try. We want to publish and publicize the draft docs at the same time. Wide ecosystem challenges Eve presented a set of high-level statements that describe the dual nature of the challenges. Eve/James and Maciej will share some material on the challenges. John observes that it's an ouroboros – a snake eating its own tail (or as Eve likes to call it, the bubble under the wallpaper that you can move but you can't remove). Some discussion arose about different solutions, e.g.: UMA-protected user claims endpoint ("UserInfo") Agreed-on central authority (e.g. hospital) serving as a claims endpoint/AS (?) – akin to the question that has arisen over the last decade-plus about "who's the IdP" The group agreed to collect all the potential solutions "without fear or favor" and then analyzes how well they solve the challenges. Attendees As of 16 Feb 2016, quorum is 6 of 10. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike) Eve Kathleen François Domenico Sal Mike Maciej Non-voting participants: John W Sarah Adrian George Scott Mark
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
-- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
To be clear, my suggestion about IdP in the #wideeco is for the #wideeco AS to be given the option of using the RS as Bob's IdP. That is very different from the RS being the IdP and AS if that's how I read the minutes. In general, I'm looking for ways to make the AS lighter and more generic so that each individual can own one. In the HIE of One brand #wideeco model, the UMA AS is also always an OpenID Connect Client so that any RS that chooses to support OIDC Dynamic OP can offer this as part of the resource registration agreement with a #wideeco AS. This also enables the AS to register other well-known IdPs like Google and make these available as a NASCAR to Bob. As blockchain ID catches on (onename <https://bitcoinmagazine.com/articles/onename-launches-blockchain-identity-product-passcard-1431548450> and uPort <https://medium.com/@ConsenSys/uport-the-wallet-is-the-new-browser-b133a83fe73#.gm1hxsgqd>), the #wideeco AS will be able to offer this as an option as well. Adrian On Thu, Feb 18, 2016 at 1:09 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Great meeting, all!
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 MinutesRoll call
Quorum was reached. Approve minutes
Minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> approved. Issue #239
- *Proposal:* Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already)
Proposal accepted.
- *Proposal:* Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension
Sal and Eve just discussed in email whether a stronger authentication mitigation would work. Session fixation happens after victim authentication, so it wouldn't help.
Robert mentioned to Eve offline that Wikipedia has some comments on session fixation that might be useful. Eve believes that since the permission ticket gets passed in UMA JSON messages, the countermeasures there may not apply, but we could look (for purposes of the non-normative analysis if ultimately nothing else).
- *For discussion:* Consider also handling issue #167 in this extension if it has a security rationale
If the AS uses the flexibility to give a new endpoint, then there's the danger of giving an attacker new information outside of the discovery document that it didn't have before, which is a degradation of security. If the AS doesn't avail itself of the flexibility, then it doesn't seem to add anything. In any case, we're not thinking of a security rationale for adding this feature to the extension. In any case, it sounds like taking up #167 as part of the extension work doesn't meet our "#security use case bucket" goals, so we'll defer that till such time as we take up "#simplify use case bucket" work.
*Consensus:* We want to write and publish the extension specification.
- *For discussion* (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG - *For discussion* (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue)
The WG itself can self-approve a technical specification, and the LC can approve that group output. (Are these "WG Reports"? Eve will check with the LC.) In other words, this could remain at a level sort of equivalent to an IETF I-D and not progress to an "RFC" level before it eventually gets absorbed into a later version of the UMA Core spec. We do want to recommend that everyone using the claims-gathering endpoint use this approach, but it all depends on the timing of any new UMA "V.next" version. We basically need to defer the decision about its "track" until we execute on the rest of our roadmap.
*AI:* Eve, Domenico, Maciej: Write the extension spec.
Can we publish these by next Thursday? Let's give the old college try. We want to publish and publicize the draft docs at the same time. Wide ecosystem challenges
Eve presented a set of high-level statements that describe the dual nature of the challenges. Eve/James and Maciej will share some material on the challenges.
John observes that it's an ouroboros – a snake eating its own tail (or as Eve likes to call it, the bubble under the wallpaper that you can move but you can't remove).
Some discussion arose about different solutions, e.g.:
- UMA-protected user claims endpoint ("UserInfo") - Agreed-on central authority (e.g. hospital) serving as a claims endpoint/AS (?) – akin to the question that has arisen over the last decade-plus about "who's the IdP"
The group agreed to collect all the potential solutions "without fear or favor" and then analyzes how well they solve the challenges. Attendees
As of 16 Feb 2016, quorum is 6 of 10. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike)
1. Eve 2. Kathleen 3. François 4. Domenico 5. Sal 6. Mike 7. Maciej
Non-voting participants:
- John W - Sarah - Adrian - George - Scott - Mark -
*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
-- 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/
A question to Adrian about the goal of making an AS lighter and more generic so that each individual can own one: Do you think it's likely that the AS function and the IdP function are likely to remain entirely separate, and not be co-located in at least some instances? (I'm guessing your answer will be yes, because you've separated out the "lightweight AS" and the "RS-as-IdP" roles here, but I may be wrong.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Feb 18, 2016 at 11:05 AM, Adrian Gropper <agropper@healthurl.com> wrote:
To be clear, my suggestion about IdP in the #wideeco is for the #wideeco AS to be given the option of using the RS as Bob's IdP. That is very different from the RS being the IdP and AS if that's how I read the minutes.
In general, I'm looking for ways to make the AS lighter and more generic so that each individual can own one. In the HIE of One brand #wideeco model, the UMA AS is also always an OpenID Connect Client so that any RS that chooses to support OIDC Dynamic OP can offer this as part of the resource registration agreement with a #wideeco AS. This also enables the AS to register other well-known IdPs like Google and make these available as a NASCAR to Bob. As blockchain ID catches on (onename <https://bitcoinmagazine.com/articles/onename-launches-blockchain-identity-product-passcard-1431548450> and uPort <https://medium.com/@ConsenSys/uport-the-wallet-is-the-new-browser-b133a83fe73#.gm1hxsgqd>), the #wideeco AS will be able to offer this as an option as well.
Adrian
On Thu, Feb 18, 2016 at 1:09 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Great meeting, all!
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 MinutesRoll call
Quorum was reached. Approve minutes
Minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> approved. Issue #239
- *Proposal:* Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already)
Proposal accepted.
- *Proposal:* Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension
Sal and Eve just discussed in email whether a stronger authentication mitigation would work. Session fixation happens after victim authentication, so it wouldn't help.
Robert mentioned to Eve offline that Wikipedia has some comments on session fixation that might be useful. Eve believes that since the permission ticket gets passed in UMA JSON messages, the countermeasures there may not apply, but we could look (for purposes of the non-normative analysis if ultimately nothing else).
- *For discussion:* Consider also handling issue #167 in this extension if it has a security rationale
If the AS uses the flexibility to give a new endpoint, then there's the danger of giving an attacker new information outside of the discovery document that it didn't have before, which is a degradation of security. If the AS doesn't avail itself of the flexibility, then it doesn't seem to add anything. In any case, we're not thinking of a security rationale for adding this feature to the extension. In any case, it sounds like taking up #167 as part of the extension work doesn't meet our "#security use case bucket" goals, so we'll defer that till such time as we take up "#simplify use case bucket" work.
*Consensus:* We want to write and publish the extension specification.
- *For discussion* (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG - *For discussion* (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue)
The WG itself can self-approve a technical specification, and the LC can approve that group output. (Are these "WG Reports"? Eve will check with the LC.) In other words, this could remain at a level sort of equivalent to an IETF I-D and not progress to an "RFC" level before it eventually gets absorbed into a later version of the UMA Core spec. We do want to recommend that everyone using the claims-gathering endpoint use this approach, but it all depends on the timing of any new UMA "V.next" version. We basically need to defer the decision about its "track" until we execute on the rest of our roadmap.
*AI:* Eve, Domenico, Maciej: Write the extension spec.
Can we publish these by next Thursday? Let's give the old college try. We want to publish and publicize the draft docs at the same time. Wide ecosystem challenges
Eve presented a set of high-level statements that describe the dual nature of the challenges. Eve/James and Maciej will share some material on the challenges.
John observes that it's an ouroboros – a snake eating its own tail (or as Eve likes to call it, the bubble under the wallpaper that you can move but you can't remove).
Some discussion arose about different solutions, e.g.:
- UMA-protected user claims endpoint ("UserInfo") - Agreed-on central authority (e.g. hospital) serving as a claims endpoint/AS (?) – akin to the question that has arisen over the last decade-plus about "who's the IdP"
The group agreed to collect all the potential solutions "without fear or favor" and then analyzes how well they solve the challenges. Attendees
As of 16 Feb 2016, quorum is 6 of 10. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike)
1. Eve 2. Kathleen 3. François 4. Domenico 5. Sal 6. Mike 7. Maciej
Non-voting participants:
- John W - Sarah - Adrian - George - Scott - Mark -
*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
--
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/
Yes, I think the separation is inevitable and is highlighted in the UMA Venn, which I hope returns to our home page soon. Identity is closely related to reputation and, as such, it needs to be mediated by things outside of the individual's control. Authorization is mostly, if not exclusively, about agency, and as such most desirable when controlled by the individual. To the extent we want UMA to serve a person-centered Web, we must make individual agency the cornerstone of our charter. This also means making the UMA AS as generic as possible so that one's AS is not disrupted by frequent, and domain-specific updates. At the risk of sounding overly medical, I approach UMA the way I would approach a prosthesis or implant in my own body. I want it to be no more complex than absolutely necessary, exteremely long-lived, independent of external or institutional supports that I would have to pay or placate, peer-reviewed open source, and invisible to others. Adrian On Thu, Feb 18, 2016 at 7:47 PM, Eve Maler <eve@xmlgrrl.com> wrote:
A question to Adrian about the goal of making an AS lighter and more generic so that each individual can own one: Do you think it's likely that the AS function and the IdP function are likely to remain entirely separate, and not be co-located in at least some instances? (I'm guessing your answer will be yes, because you've separated out the "lightweight AS" and the "RS-as-IdP" roles here, but I may be wrong.)
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Feb 18, 2016 at 11:05 AM, Adrian Gropper <agropper@healthurl.com> wrote:
To be clear, my suggestion about IdP in the #wideeco is for the #wideeco AS to be given the option of using the RS as Bob's IdP. That is very different from the RS being the IdP and AS if that's how I read the minutes.
In general, I'm looking for ways to make the AS lighter and more generic so that each individual can own one. In the HIE of One brand #wideeco model, the UMA AS is also always an OpenID Connect Client so that any RS that chooses to support OIDC Dynamic OP can offer this as part of the resource registration agreement with a #wideeco AS. This also enables the AS to register other well-known IdPs like Google and make these available as a NASCAR to Bob. As blockchain ID catches on (onename <https://bitcoinmagazine.com/articles/onename-launches-blockchain-identity-product-passcard-1431548450> and uPort <https://medium.com/@ConsenSys/uport-the-wallet-is-the-new-browser-b133a83fe73#.gm1hxsgqd>), the #wideeco AS will be able to offer this as an option as well.
Adrian
On Thu, Feb 18, 2016 at 1:09 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Great meeting, all!
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 MinutesRoll call
Quorum was reached. Approve minutes
Minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> approved. Issue #239
- *Proposal:* Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already)
Proposal accepted.
- *Proposal:* Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension
Sal and Eve just discussed in email whether a stronger authentication mitigation would work. Session fixation happens after victim authentication, so it wouldn't help.
Robert mentioned to Eve offline that Wikipedia has some comments on session fixation that might be useful. Eve believes that since the permission ticket gets passed in UMA JSON messages, the countermeasures there may not apply, but we could look (for purposes of the non-normative analysis if ultimately nothing else).
- *For discussion:* Consider also handling issue #167 in this extension if it has a security rationale
If the AS uses the flexibility to give a new endpoint, then there's the danger of giving an attacker new information outside of the discovery document that it didn't have before, which is a degradation of security. If the AS doesn't avail itself of the flexibility, then it doesn't seem to add anything. In any case, we're not thinking of a security rationale for adding this feature to the extension. In any case, it sounds like taking up #167 as part of the extension work doesn't meet our "#security use case bucket" goals, so we'll defer that till such time as we take up "#simplify use case bucket" work.
*Consensus:* We want to write and publish the extension specification.
- *For discussion* (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG - *For discussion* (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue)
The WG itself can self-approve a technical specification, and the LC can approve that group output. (Are these "WG Reports"? Eve will check with the LC.) In other words, this could remain at a level sort of equivalent to an IETF I-D and not progress to an "RFC" level before it eventually gets absorbed into a later version of the UMA Core spec. We do want to recommend that everyone using the claims-gathering endpoint use this approach, but it all depends on the timing of any new UMA "V.next" version. We basically need to defer the decision about its "track" until we execute on the rest of our roadmap.
*AI:* Eve, Domenico, Maciej: Write the extension spec.
Can we publish these by next Thursday? Let's give the old college try. We want to publish and publicize the draft docs at the same time. Wide ecosystem challenges
Eve presented a set of high-level statements that describe the dual nature of the challenges. Eve/James and Maciej will share some material on the challenges.
John observes that it's an ouroboros – a snake eating its own tail (or as Eve likes to call it, the bubble under the wallpaper that you can move but you can't remove).
Some discussion arose about different solutions, e.g.:
- UMA-protected user claims endpoint ("UserInfo") - Agreed-on central authority (e.g. hospital) serving as a claims endpoint/AS (?) – akin to the question that has arisen over the last decade-plus about "who's the IdP"
The group agreed to collect all the potential solutions "without fear or favor" and then analyzes how well they solve the challenges. Attendees
As of 16 Feb 2016, quorum is 6 of 10. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike)
1. Eve 2. Kathleen 3. François 4. Domenico 5. Sal 6. Mike 7. Maciej
Non-voting participants:
- John W - Sarah - Adrian - George - Scott - Mark -
*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
--
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/
-- 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/
It seems to me that this elides several use cases. If we set aside the currently unrealistic expectation that each person will own one or more AS’s, then the most likely location for a self-owned AS is in the home, or in a cloud service provided to the individual (a cloud home so to speak). I can see where I’ll want to use an authoritative IdP for some kinds of transactions and identities - health (hospital as IdP) and finance (bank as IdP) - but I can see multiple scenarios involving social identity where I would want to self assert to have the capability for multiple (disposable) identities. This isn’t just the case for teenagers and trolls, but would also be the case for human rights workers and democracy activists in any number of countries. Sincerely, John Wunderlich (@PrivacyCDN) <http://privacybydesign.ca/> <http://privacybydesign.ca/> <http://privacybydesign.ca/>Privacist & PbD Ambassador <http://privacybydesign.ca/>
On Feb 18, 2016, at 19:47, Eve Maler <eve@xmlgrrl.com> wrote:
A question to Adrian about the goal of making an AS lighter and more generic so that each individual can own one: Do you think it's likely that the AS function and the IdP function are likely to remain entirely separate, and not be co-located in at least some instances? (I'm guessing your answer will be yes, because you've separated out the "lightweight AS" and the "RS-as-IdP" roles here, but I may be wrong.)
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Feb 18, 2016 at 11:05 AM, Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com>> wrote: To be clear, my suggestion about IdP in the #wideeco is for the #wideeco AS to be given the option of using the RS as Bob's IdP. That is very different from the RS being the IdP and AS if that's how I read the minutes.
In general, I'm looking for ways to make the AS lighter and more generic so that each individual can own one. In the HIE of One brand #wideeco model, the UMA AS is also always an OpenID Connect Client so that any RS that chooses to support OIDC Dynamic OP can offer this as part of the resource registration agreement with a #wideeco AS. This also enables the AS to register other well-known IdPs like Google and make these available as a NASCAR to Bob. As blockchain ID catches on (onename <https://bitcoinmagazine.com/articles/onename-launches-blockchain-identity-product-passcard-1431548450> and uPort <https://medium.com/@ConsenSys/uport-the-wallet-is-the-new-browser-b133a83fe73#.gm1hxsgqd>), the #wideeco AS will be able to offer this as an option as well.
Adrian
On Thu, Feb 18, 2016 at 1:09 PM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: Great meeting, all!
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18> Minutes Roll call Quorum was reached. Approve minutes Minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> approved. Issue #239 Proposal: Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already) Proposal accepted. Proposal: Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension Sal and Eve just discussed in email whether a stronger authentication mitigation would work. Session fixation happens after victim authentication, so it wouldn't help. Robert mentioned to Eve offline that Wikipedia has some comments on session fixation that might be useful. Eve believes that since the permission ticket gets passed in UMA JSON messages, the countermeasures there may not apply, but we could look (for purposes of the non-normative analysis if ultimately nothing else). For discussion: Consider also handling issue #167 in this extension if it has a security rationale If the AS uses the flexibility to give a new endpoint, then there's the danger of giving an attacker new information outside of the discovery document that it didn't have before, which is a degradation of security. If the AS doesn't avail itself of the flexibility, then it doesn't seem to add anything. In any case, we're not thinking of a security rationale for adding this feature to the extension. In any case, it sounds like taking up #167 as part of the extension work doesn't meet our "#security use case bucket" goals, so we'll defer that till such time as we take up "#simplify use case bucket" work. Consensus: We want to write and publish the extension specification. For discussion (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG For discussion (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue) The WG itself can self-approve a technical specification, and the LC can approve that group output. (Are these "WG Reports"? Eve will check with the LC.) In other words, this could remain at a level sort of equivalent to an IETF I-D and not progress to an "RFC" level before it eventually gets absorbed into a later version of the UMA Core spec. We do want to recommend that everyone using the claims-gathering endpoint use this approach, but it all depends on the timing of any new UMA "V.next" version. We basically need to defer the decision about its "track" until we execute on the rest of our roadmap. AI: Eve, Domenico, Maciej: Write the extension spec. Can we publish these by next Thursday? Let's give the old college try. We want to publish and publicize the draft docs at the same time. Wide ecosystem challenges Eve presented a set of high-level statements that describe the dual nature of the challenges. Eve/James and Maciej will share some material on the challenges. John observes that it's an ouroboros – a snake eating its own tail (or as Eve likes to call it, the bubble under the wallpaper that you can move but you can't remove). Some discussion arose about different solutions, e.g.: UMA-protected user claims endpoint ("UserInfo") Agreed-on central authority (e.g. hospital) serving as a claims endpoint/AS (?) – akin to the question that has arisen over the last decade-plus about "who's the IdP" The group agreed to collect all the potential solutions "without fear or favor" and then analyzes how well they solve the challenges. Attendees As of 16 Feb 2016, quorum is 6 of 10. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike) Eve Kathleen François Domenico Sal Mike Maciej Non-voting participants: John W Sarah Adrian George Scott Mark
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <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/ <http://patientprivacyrights.org/donate-2/> _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
John, We seem to agree that the AS is naturally separate from whatever IdPs and credential brokers will evolve. The opportunity to own one's AS in the cloud is more realistic every day. A microservices architecture like AWS Lambda can expose HTTPS endpoints with Let's Encrypt certificates without the hassle of managing OS and OS security for a VM. AWS Lambda can run a personal UMA AS written in Node or Python (like HIE of One) using almost no resources and might cost less than the $10 / year that I pay for the personal domain. I see an UMA AS becoming like the email forwarding service offered for free by some registrars with just a more complex user interface. Adrian On Fri, Feb 19, 2016 at 9:54 AM, John Wunderlich <john@wunderlich.ca> wrote:
It seems to me that this elides several use cases. If we set aside the currently unrealistic expectation that each person will own one or more AS’s, then the most likely location for a self-owned AS is in the home, or in a cloud service provided to the individual (a cloud home so to speak). I can see where I’ll want to use an authoritative IdP for some kinds of transactions and identities - health (hospital as IdP) and finance (bank as IdP) - but I can see multiple scenarios involving social identity where I would want to self assert to have the capability for multiple (disposable) identities. This isn’t just the case for teenagers and trolls, but would also be the case for human rights workers and democracy activists in any number of countries.
Sincerely, *John Wunderlich* *(@PrivacyCDN)*
<http://privacybydesign.ca> <http://privacybydesign.ca>
<http://privacybydesign.ca>Privacist & PbD Ambassador <http://privacybydesign.ca>
On Feb 18, 2016, at 19:47, Eve Maler <eve@xmlgrrl.com> wrote:
A question to Adrian about the goal of making an AS lighter and more generic so that each individual can own one: Do you think it's likely that the AS function and the IdP function are likely to remain entirely separate, and not be co-located in at least some instances? (I'm guessing your answer will be yes, because you've separated out the "lightweight AS" and the "RS-as-IdP" roles here, but I may be wrong.)
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Feb 18, 2016 at 11:05 AM, Adrian Gropper <agropper@healthurl.com> wrote:
To be clear, my suggestion about IdP in the #wideeco is for the #wideeco AS to be given the option of using the RS as Bob's IdP. That is very different from the RS being the IdP and AS if that's how I read the minutes.
In general, I'm looking for ways to make the AS lighter and more generic so that each individual can own one. In the HIE of One brand #wideeco model, the UMA AS is also always an OpenID Connect Client so that any RS that chooses to support OIDC Dynamic OP can offer this as part of the resource registration agreement with a #wideeco AS. This also enables the AS to register other well-known IdPs like Google and make these available as a NASCAR to Bob. As blockchain ID catches on (onename <https://bitcoinmagazine.com/articles/onename-launches-blockchain-identity-product-passcard-1431548450> and uPort <https://medium.com/@ConsenSys/uport-the-wallet-is-the-new-browser-b133a83fe73#.gm1hxsgqd>), the #wideeco AS will be able to offer this as an option as well.
Adrian
On Thu, Feb 18, 2016 at 1:09 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Great meeting, all!
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 MinutesRoll call
Quorum was reached. Approve minutes
Minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> approved. Issue #239
- *Proposal:* Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already)
Proposal accepted.
- *Proposal:* Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension
Sal and Eve just discussed in email whether a stronger authentication mitigation would work. Session fixation happens after victim authentication, so it wouldn't help.
Robert mentioned to Eve offline that Wikipedia has some comments on session fixation that might be useful. Eve believes that since the permission ticket gets passed in UMA JSON messages, the countermeasures there may not apply, but we could look (for purposes of the non-normative analysis if ultimately nothing else).
- *For discussion:* Consider also handling issue #167 in this extension if it has a security rationale
If the AS uses the flexibility to give a new endpoint, then there's the danger of giving an attacker new information outside of the discovery document that it didn't have before, which is a degradation of security. If the AS doesn't avail itself of the flexibility, then it doesn't seem to add anything. In any case, we're not thinking of a security rationale for adding this feature to the extension. In any case, it sounds like taking up #167 as part of the extension work doesn't meet our "#security use case bucket" goals, so we'll defer that till such time as we take up "#simplify use case bucket" work.
*Consensus:* We want to write and publish the extension specification.
- *For discussion* (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG - *For discussion* (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue)
The WG itself can self-approve a technical specification, and the LC can approve that group output. (Are these "WG Reports"? Eve will check with the LC.) In other words, this could remain at a level sort of equivalent to an IETF I-D and not progress to an "RFC" level before it eventually gets absorbed into a later version of the UMA Core spec. We do want to recommend that everyone using the claims-gathering endpoint use this approach, but it all depends on the timing of any new UMA "V.next" version. We basically need to defer the decision about its "track" until we execute on the rest of our roadmap.
*AI:* Eve, Domenico, Maciej: Write the extension spec.
Can we publish these by next Thursday? Let's give the old college try. We want to publish and publicize the draft docs at the same time. Wide ecosystem challenges
Eve presented a set of high-level statements that describe the dual nature of the challenges. Eve/James and Maciej will share some material on the challenges.
John observes that it's an ouroboros – a snake eating its own tail (or as Eve likes to call it, the bubble under the wallpaper that you can move but you can't remove).
Some discussion arose about different solutions, e.g.:
- UMA-protected user claims endpoint ("UserInfo") - Agreed-on central authority (e.g. hospital) serving as a claims endpoint/AS (?) – akin to the question that has arisen over the last decade-plus about "who's the IdP"
The group agreed to collect all the potential solutions "without fear or favor" and then analyzes how well they solve the challenges. Attendees
As of 16 Feb 2016, quorum is 6 of 10. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike)
1. Eve 2. Kathleen 3. François 4. Domenico 5. Sal 6. Mike 7. Maciej
Non-voting participants:
- John W - Sarah - Adrian - George - Scott - Mark -
*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
--
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
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
-- 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/
Adrian; Owning/operating an AS is not unrealistic technically. It’s unrealistic In the same way that most people CAN change their own oil in their cars, but don’t. I suspect that most people’s view - even after an explanation of how UMA works - is that it would be too much trouble to own/manager their own AS. If/when the AS becomes an app on their phone, or a key fob with a one button press functionality, (assuming that carrying your AS with is a good thing) then the case would be different - and would suggest a separation of AS from IdP(s). Sincerely, John Wunderlich (@PrivacyCDN) <http://privacybydesign.ca/> <http://privacybydesign.ca/> <http://privacybydesign.ca/>Privacist & PbD Ambassador <http://privacybydesign.ca/>
On Feb 19, 2016, at 10:14, Adrian Gropper <agropper@healthurl.com> wrote:
John,
We seem to agree that the AS is naturally separate from whatever IdPs and credential brokers will evolve.
The opportunity to own one's AS in the cloud is more realistic every day. A microservices architecture like AWS Lambda can expose HTTPS endpoints with Let's Encrypt certificates without the hassle of managing OS and OS security for a VM. AWS Lambda can run a personal UMA AS written in Node or Python (like HIE of One) using almost no resources and might cost less than the $10 / year that I pay for the personal domain. I see an UMA AS becoming like the email forwarding service offered for free by some registrars with just a more complex user interface.
Adrian
On Fri, Feb 19, 2016 at 9:54 AM, John Wunderlich <john@wunderlich.ca <mailto:john@wunderlich.ca>> wrote: It seems to me that this elides several use cases. If we set aside the currently unrealistic expectation that each person will own one or more AS’s, then the most likely location for a self-owned AS is in the home, or in a cloud service provided to the individual (a cloud home so to speak). I can see where I’ll want to use an authoritative IdP for some kinds of transactions and identities - health (hospital as IdP) and finance (bank as IdP) - but I can see multiple scenarios involving social identity where I would want to self assert to have the capability for multiple (disposable) identities. This isn’t just the case for teenagers and trolls, but would also be the case for human rights workers and democracy activists in any number of countries.
Sincerely, John Wunderlich (@PrivacyCDN)
<PastedGraphic-4.tiff> <http://privacybydesign.ca/> <http://privacybydesign.ca/>
<http://privacybydesign.ca/>Privacist & PbD Ambassador <http://privacybydesign.ca/>
On Feb 18, 2016, at 19:47, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
A question to Adrian about the goal of making an AS lighter and more generic so that each individual can own one: Do you think it's likely that the AS function and the IdP function are likely to remain entirely separate, and not be co-located in at least some instances? (I'm guessing your answer will be yes, because you've separated out the "lightweight AS" and the "RS-as-IdP" roles here, but I may be wrong.)
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Feb 18, 2016 at 11:05 AM, Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com>> wrote: To be clear, my suggestion about IdP in the #wideeco is for the #wideeco AS to be given the option of using the RS as Bob's IdP. That is very different from the RS being the IdP and AS if that's how I read the minutes.
In general, I'm looking for ways to make the AS lighter and more generic so that each individual can own one. In the HIE of One brand #wideeco model, the UMA AS is also always an OpenID Connect Client so that any RS that chooses to support OIDC Dynamic OP can offer this as part of the resource registration agreement with a #wideeco AS. This also enables the AS to register other well-known IdPs like Google and make these available as a NASCAR to Bob. As blockchain ID catches on (onename <https://bitcoinmagazine.com/articles/onename-launches-blockchain-identity-product-passcard-1431548450> and uPort <https://medium.com/@ConsenSys/uport-the-wallet-is-the-new-browser-b133a83fe73#.gm1hxsgqd>), the #wideeco AS will be able to offer this as an option as well.
Adrian
On Thu, Feb 18, 2016 at 1:09 PM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: Great meeting, all!
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18> Minutes Roll call Quorum was reached. Approve minutes Minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> approved. Issue #239 Proposal: Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already) Proposal accepted. Proposal: Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension Sal and Eve just discussed in email whether a stronger authentication mitigation would work. Session fixation happens after victim authentication, so it wouldn't help. Robert mentioned to Eve offline that Wikipedia has some comments on session fixation that might be useful. Eve believes that since the permission ticket gets passed in UMA JSON messages, the countermeasures there may not apply, but we could look (for purposes of the non-normative analysis if ultimately nothing else). For discussion: Consider also handling issue #167 in this extension if it has a security rationale If the AS uses the flexibility to give a new endpoint, then there's the danger of giving an attacker new information outside of the discovery document that it didn't have before, which is a degradation of security. If the AS doesn't avail itself of the flexibility, then it doesn't seem to add anything. In any case, we're not thinking of a security rationale for adding this feature to the extension. In any case, it sounds like taking up #167 as part of the extension work doesn't meet our "#security use case bucket" goals, so we'll defer that till such time as we take up "#simplify use case bucket" work. Consensus: We want to write and publish the extension specification. For discussion (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG For discussion (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue) The WG itself can self-approve a technical specification, and the LC can approve that group output. (Are these "WG Reports"? Eve will check with the LC.) In other words, this could remain at a level sort of equivalent to an IETF I-D and not progress to an "RFC" level before it eventually gets absorbed into a later version of the UMA Core spec. We do want to recommend that everyone using the claims-gathering endpoint use this approach, but it all depends on the timing of any new UMA "V.next" version. We basically need to defer the decision about its "track" until we execute on the rest of our roadmap. AI: Eve, Domenico, Maciej: Write the extension spec. Can we publish these by next Thursday? Let's give the old college try. We want to publish and publicize the draft docs at the same time. Wide ecosystem challenges Eve presented a set of high-level statements that describe the dual nature of the challenges. Eve/James and Maciej will share some material on the challenges. John observes that it's an ouroboros – a snake eating its own tail (or as Eve likes to call it, the bubble under the wallpaper that you can move but you can't remove). Some discussion arose about different solutions, e.g.: UMA-protected user claims endpoint ("UserInfo") Agreed-on central authority (e.g. hospital) serving as a claims endpoint/AS (?) – akin to the question that has arisen over the last decade-plus about "who's the IdP" The group agreed to collect all the potential solutions "without fear or favor" and then analyzes how well they solve the challenges. Attendees As of 16 Feb 2016, quorum is 6 of 10. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike) Eve Kathleen François Domenico Sal Mike Maciej Non-voting participants: John W Sarah Adrian George Scott Mark
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <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/ <http://patientprivacyrights.org/donate-2/> _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
--
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/ <http://patientprivacyrights.org/donate-2/>
-- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
I agree with you both that it's technically feasible for a single person to run a personal AS. From a practical "ecosystem growth" standpoint, I wonder whether certain other service/app operators might have some (irrational? perceptual?) issue with dealing with an AS whose Operator is the Authorizing Party. We already know certain RS's (*coff* hospitals) are nervous to outsource authorization to a third party at all (the genesis of the Binding Obs work). I wonder if the best shot for people running their own personal AS's might actually be a "smart home hub". We're already seeing home VPN devices billed as "privacy" products, along with other devices that control multiple other IoT thingies. Eve Maler (sent from my iPad) | cell +1 425 345 6756
On Feb 19, 2016, at 7:53 AM, John Wunderlich <john@wunderlich.ca> wrote:
Adrian;
Owning/operating an AS is not unrealistic technically. It’s unrealistic In the same way that most people CAN change their own oil in their cars, but don’t.
I suspect that most people’s view - even after an explanation of how UMA works - is that it would be too much trouble to own/manager their own AS. If/when the AS becomes an app on their phone, or a key fob with a one button press functionality, (assuming that carrying your AS with is a good thing) then the case would be different - and would suggest a separation of AS from IdP(s).
Sincerely, John Wunderlich (@PrivacyCDN)
<PastedGraphic-4.tiff>
Privacist & PbD Ambassador
On Feb 19, 2016, at 10:14, Adrian Gropper <agropper@healthurl.com> wrote:
John,
We seem to agree that the AS is naturally separate from whatever IdPs and credential brokers will evolve.
The opportunity to own one's AS in the cloud is more realistic every day. A microservices architecture like AWS Lambda can expose HTTPS endpoints with Let's Encrypt certificates without the hassle of managing OS and OS security for a VM. AWS Lambda can run a personal UMA AS written in Node or Python (like HIE of One) using almost no resources and might cost less than the $10 / year that I pay for the personal domain. I see an UMA AS becoming like the email forwarding service offered for free by some registrars with just a more complex user interface.
Adrian
On Fri, Feb 19, 2016 at 9:54 AM, John Wunderlich <john@wunderlich.ca> wrote: It seems to me that this elides several use cases. If we set aside the currently unrealistic expectation that each person will own one or more AS’s, then the most likely location for a self-owned AS is in the home, or in a cloud service provided to the individual (a cloud home so to speak). I can see where I’ll want to use an authoritative IdP for some kinds of transactions and identities - health (hospital as IdP) and finance (bank as IdP) - but I can see multiple scenarios involving social identity where I would want to self assert to have the capability for multiple (disposable) identities. This isn’t just the case for teenagers and trolls, but would also be the case for human rights workers and democracy activists in any number of countries.
Sincerely, John Wunderlich (@PrivacyCDN)
<PastedGraphic-4.tiff>
Privacist & PbD Ambassador
On Feb 18, 2016, at 19:47, Eve Maler <eve@xmlgrrl.com> wrote:
A question to Adrian about the goal of making an AS lighter and more generic so that each individual can own one: Do you think it's likely that the AS function and the IdP function are likely to remain entirely separate, and not be co-located in at least some instances? (I'm guessing your answer will be yes, because you've separated out the "lightweight AS" and the "RS-as-IdP" roles here, but I may be wrong.)
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Feb 18, 2016 at 11:05 AM, Adrian Gropper <agropper@healthurl.com> wrote: To be clear, my suggestion about IdP in the #wideeco is for the #wideeco AS to be given the option of using the RS as Bob's IdP. That is very different from the RS being the IdP and AS if that's how I read the minutes.
In general, I'm looking for ways to make the AS lighter and more generic so that each individual can own one. In the HIE of One brand #wideeco model, the UMA AS is also always an OpenID Connect Client so that any RS that chooses to support OIDC Dynamic OP can offer this as part of the resource registration agreement with a #wideeco AS. This also enables the AS to register other well-known IdPs like Google and make these available as a NASCAR to Bob. As blockchain ID catches on (onename and uPort), the #wideeco AS will be able to offer this as an option as well.
Adrian
On Thu, Feb 18, 2016 at 1:09 PM, Eve Maler <eve@xmlgrrl.com> wrote: Great meeting, all!
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 Minutes Roll call Quorum was reached. Approve minutes Minutes of UMA telecon 2016-01-07 approved. Issue #239 Proposal: Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already) Proposal accepted. Proposal: Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension Sal and Eve just discussed in email whether a stronger authentication mitigation would work. Session fixation happens after victim authentication, so it wouldn't help. Robert mentioned to Eve offline that Wikipedia has some comments on session fixation that might be useful. Eve believes that since the permission ticket gets passed in UMA JSON messages, the countermeasures there may not apply, but we could look (for purposes of the non-normative analysis if ultimately nothing else). For discussion: Consider also handling issue #167 in this extension if it has a security rationale If the AS uses the flexibility to give a new endpoint, then there's the danger of giving an attacker new information outside of the discovery document that it didn't have before, which is a degradation of security. If the AS doesn't avail itself of the flexibility, then it doesn't seem to add anything. In any case, we're not thinking of a security rationale for adding this feature to the extension. In any case, it sounds like taking up #167 as part of the extension work doesn't meet our "#security use case bucket" goals, so we'll defer that till such time as we take up "#simplify use case bucket" work. Consensus: We want to write and publish the extension specification. For discussion (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG For discussion (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue) The WG itself can self-approve a technical specification, and the LC can approve that group output. (Are these "WG Reports"? Eve will check with the LC.) In other words, this could remain at a level sort of equivalent to an IETF I-D and not progress to an "RFC" level before it eventually gets absorbed into a later version of the UMA Core spec. We do want to recommend that everyone using the claims-gathering endpoint use this approach, but it all depends on the timing of any new UMA "V.next" version. We basically need to defer the decision about its "track" until we execute on the rest of our roadmap. AI: Eve, Domenico, Maciej: Write the extension spec. Can we publish these by next Thursday? Let's give the old college try. We want to publish and publicize the draft docs at the same time. Wide ecosystem challenges Eve presented a set of high-level statements that describe the dual nature of the challenges. Eve/James and Maciej will share some material on the challenges. John observes that it's an ouroboros – a snake eating its own tail (or as Eve likes to call it, the bubble under the wallpaper that you can move but you can't remove). Some discussion arose about different solutions, e.g.: UMA-protected user claims endpoint ("UserInfo") Agreed-on central authority (e.g. hospital) serving as a claims endpoint/AS (?) – akin to the question that has arisen over the last decade-plus about "who's the IdP" The group agreed to collect all the potential solutions "without fear or favor" and then analyzes how well they solve the challenges. Attendees As of 16 Feb 2016, quorum is 6 of 10. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike) Eve Kathleen François Domenico Sal Mike Maciej Non-voting participants: John W Sarah Adrian George Scott Mark
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
--
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
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
--
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/
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. <signature.asc>
participants (3)
-
Adrian Gropper -
Eve Maler -
John Wunderlich