User-Managed Access: Why and How? - Access Control in Digital Contract Contexts

576 views

Published on

Presentation by Eve Maler, VP Innovation and Emerging Technologies, ForgeRock at the Digital Identities, Contracts, and Blockchain Conference at MIT

Published in: Software
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
576
On SlideShare
0
From Embeds
0
Number of Embeds
29
Actions
Shares
0
Downloads
34
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Consumer trust of businesses has never been great.
    But it’s demonstrably at an ebb in the post-Snowden era when it comes to personal data.
    There’s qualitative and quantitative evidence telling the story.

    Image source: https://www.flickr.com/photos/vincrosbie/16301598031/
  • Latest evidence:
    Spotify last August: simple privacy policy change alarmed customers
    Complaints, threats to leave (e.g. new Apple Music)
    Lesson: commoditized? low switching costs, lack of sensitivity can hurt you even if the change wasn’t materially negative
    Mobile Ecosystem Forum IoT consumer survey: trust issues biggest concern

    (See: http://www.dw.com/en/spotify-feels-the-burn-after-privacy-policy-flub/a-18665269)
    (See: http://www.bizreport.com/2016/04/21-globally-have-concerns-that-iot-machines-will-take-over-t.html)
    Image source: https://www.flickr.com/photos/vincrosbie/16301598031/
  • Spotify shows how businesses can lose when you can’t sustain trustworthiness
    Cash economy means you might have had only a single customer interaction – digital economy nearly always means repeated interactions
    This makes the game theoretical stakes higher
    In a moment we’ll talk about the upside potential
    What about the compliance costs and penalties?
    They’re more substantial than ever (GDPR: up to 4% of worldwide turnover, DPO, etc.)
    But they’re clearly not about relationships with customers and end-users

    Image sources:
    https://www.flickr.com/photos/delmo-baggins/3143080675
    http://www.huffingtonpost.com/marguerite-orane/worklife-not-balanced-enj_b_7189918.html
  • Use health, including consumer and clinical health devices, as an example
    The HEART Work Group at OpenID Foundation is working on a use case
    I’m a co-chair of the group
    Alice Selectively Shares Health-Related Data with Physicians and Others
    For example, one flow enables Alice to choose to share basic data about herself with a doctor before her first visit
    Another lets Alice monitor and control access
    There’s a flow involving Alice sharing the list of her medications with her spouse
    And one where Alice agrees to donate data to clinical research in deidentified fashion

    (See: Economics of Privacy: p. 15: “strategic consumers may make a firm worse off in the context of dynamic targeted pricing”)
    (See: https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR)
  • Okay, so why enable personal data sharing?
    Data quality and accuracy -- one US study: only 5% agreement between medications listed in EHRs and what patients actually take
    This gap affects cost, efficiency, and satisfaction as well
    Improved clinical research sets – one UK study: over half the respondents supported use of their data by commercial organizations for research
    A floor of 17% were not willing to share data at all
    Better care – Philips did a study with Banner Health
    Patients with chronic disease using a smart device and an app would tend to leverage continuously monitored vital signs
    Shorter, less expensive, less ER-intensive stay: savings averaged 10 days/year and $27K/year

    (See: http://well.blogs.nytimes.com/2016/03/31/let-patients-read-their-medical-records/?_r=0)
    (See: http://www.wellcome.ac.uk/News/Media-office/Press-releases/2016/WTP060240.htm)

    Image sources:
    http://www.serkworks.com/rocket-surgery-institute/
    https://upload.wikimedia.org/wikipedia/en/d/dc/Lab_Rats_Film_Poster.jpg
    http://www.mastgeneralstore.com/products/id-1426/magnet_-_i_love_lucy_vitameatavegamin
  • So that’s a business-based reward-centric viewpoint
    Beyond the business-based risk-centric viewpoint of regulatory compliance, why should businesses do what individuals want regarding personal control?
    The IoT brings new volumes and sources of data, and new use cases for people wanting to share that data
    CareKit added person-to-person sharing in the Apple ecosystem
    Dumb socks vs. smart socks – need a solution in wider ecosystems
  • How can we meet these needs?
    Are the tools and technologies we have available actually ready?
    ForgeRock asked companies if current methods such as opt-in checkboxes and cookie acknowledgment flows can adapt
    Only 9% think they can
    However, all is not lost.

    (See: https://www.forgerock.com/about-us/press-releases/new-global-survey-finds-companies-lack-adequate-data-privacy-consent-tools-todays-evolving-regulations-dynamic-digital-economy/)
    Image source: https://www.etsy.com/listing/184845181/quotation-marks-temporary-tattoo-set-of
  • It’s a good thing we’re seeing this innovation
    Recent TRUSTe Safe Harbor Poll: after Safe Harbor invalidated: respondents approximately tripled use of consent for ensuring EU data transfer compliance
    What could the delegation, consent, and access experience look like in UMA?
    Let’s look briefly at a consumer health IoT scenario where UMA provides a linchpin for needed capabilities
  • Is a standard built on OAuth 2.0
    Delivers externalized authorization
    Provides digital consent control to end users
    Allows to share data and revoke access to data
  • User-Managed Access: Why and How? - Access Control in Digital Contract Contexts

    1. 1. © 2016 ForgeRock. All rights reserved. User-Managed Access: Why and How? Access Control in Digital Contract Contexts Eve Maler VP Innovation & Emerging Technology, ForgeRock @xmlgrrl
    2. 2. © 2016 ForgeRock. All rights reserved. From IAM to IRM Digital business requires an identity-centric approach Identity Access Management Identity Relationship Management Customers (millions) On-premises People Applications and data PCs Endpoints Workforce (thousands) Partners and Suppliers Customers (millions) On-premises Public Cloud Private Cloud People Things (Tens of millions) Applications and data PCs PhonesTablets Smart Watches Endpoints Source: Forrester Research
    3. 3. © 2016 ForgeRock. All rights reserved. The bits and bytes of identity, access, and relationship management UMA Provider Mobile App Synchronization Auditing LDAPv3 REST/JSON Replication Access Control Schema Management Caching Auditing Monitoring Groups Password Policy Active Directory Pass-thru Reporting Authentication Authorization Provisioning User Self-Service Authentication OIDC / OAuth2 Federation / SSO User Self-Service Workflow Engine Reconciliation Password Replay SAML2 Adaptive Risk Stateless/Stateful Registration Aggregated User View Message Transformation API Security Scripting Built from Open Source Projects: UMA Protector Access Management Identity Management Identity Gateway Directory Services CommonRESTAPI CommonUserInterface CommonAudit/Logging CommonScripting
    4. 4. © 2016 ForgeRock. All rights reserved. We generally don’t “do identity” just for fun… protect ion personalizat ion payment
    5. 5. © 2016 ForgeRock. All rights reserved. It’s a rare source of information that doesn’t require serious permissioning for access
    6. 6. © 2016 ForgeRock. All rights reserved. 6 flickr.com/photos/vincrosbie/16301598031/ CC BY-ND 2.0
    7. 7. © 2016 ForgeRock. All rights reserved. flickr.com/photos/vincrosbie/16301598031/ CC BY-ND 2.0
    8. 8. © 2016 ForgeRock. All rights reserved. What happens when businesses can’t form trusted digital relationships with consumers? • Revenue loss • Brand damage • Loss of trust • Missing out on opportunities • Compliance costs and penalties? flickr.com/photos/delmo-baggins/3143080675 CC BY-ND 2.0
    9. 9. © 2016 ForgeRock. All rights reserved. Why enable personal data sharing? Let’s use Health Relationship Trust as an example
    10. 10. © 2016 ForgeRock. All rights reserved. data quality and accuracy improved clinical data better care
    11. 11. © 2016 ForgeRock. All rights reserved. Why ensure personal control of sharing?
    12. 12. © 2016 ForgeRock. All rights reserved. To empower individuals as legal parties, give them (us) permissioning tools
    13. 13. © 2016 ForgeRock. All rights reserved. To empower individuals as legal parties, give them permissioning tools • Alice: • Wants to grant access to her medical power of attorney: • To spouse Bob: Persistently • To her medical professionals: When setting up and going through a procedure • To first responders: In an emergency situation • Wants to sell access to her professional high-resolution photos: • From a central control console: Operating across her several photo services • Integrating to a variety of applications: To reach the widest market • Incorporating a smart contract component: To enable fair, efficient agreement
    14. 14. © 2016 ForgeRock. All rights reserved. How dire is the “consent tech” situation? 9 percent [of companies] believe current methods (i.e., check boxes, cookie acknowledgment) used to ensure data privacy and consent will be able to adapt to the needs of the emerging digital economy. – ForgeRock global survey conducted by TechValidate, 16 Mar 2016
    15. 15. © 2016 ForgeRock. All rights reserved. The next generation of consent standards is riding to the rescue 1. innovates coarse-grained consent withdrawal 2. leverages OAuth for portable identity 3. adds multi-party delegation, finer- grained withdrawal, central console 4. profiles #1, #2, #3 and the FHIR API for patient centricity 5. defines consent receipts 6. codifies and automates legal docs and consents
    16. 16. © 2016 ForgeRock. All rights reserved. USER-MANAGED ACCESS A new standard for data sharing and control Regard for one's wishes and preferences The true ability to say no and change one's mind The ability to share just the right amount The right moment to make the decision to share Context Control RespectChoice http://tinyurl.com/umawg http://tinyurl.com/umalegal @UMAWG
    17. 17. © 2016 ForgeRock. All rights reserved. authorization server resource owner requesting party client manage control protect delegate revoke authorize manage access negotiate deny A demo scenario resource server Sharing access to: • Identity attributes • Consumer health device • Contract clauses • …?
    18. 18. © 2016 ForgeRock. All rights reserved.
    19. 19. © 2016 ForgeRock. All rights reserved. OAuth does “RESTful WS- Security,” capturing user consent for app access and respecting its withdrawal RS resource server AS authorization server C client Both servers are run by the same organization; RO goes to AS in each ecosystem to revoke its token Standard OAuth endpoints that manage access token issuance API endpoints that deliver the data or other “value-add” App gets the consent based on the API “scopes” (permissions) it requested; is uniquely identified vs. the user RO resource owner Authorizes (consents) at run time after authenticating
    20. 20. © 2016 ForgeRock. All rights reserved. OpenID Connect Turns Single Sign-On Into an OAuth-Protected Identity API SAML 2, OpenID 2 OAuth 2 OpenID Connect Initiating user’s login session Collecting user consent High-security identity tokens Distributed/aggregated claims Dynamic introduction (OpenID only) Session management No sessions Collecting user consent No identity tokens per se No claims per se Dynamic introduction (new) No sessions X X X X X X X Initiating user’s login session Collecting user consent High-security identity tokens Distributed/aggregated claims Dynamic introduction Session management (draft)
    21. 21. © 2016 ForgeRock. All rights reserved. UMA adds party-to-party, asynchronous, scope-grained delegation and control to OAuth Loosely coupled to enable centralized authorization and a central sharing management hub Enables party-to-party sharing – without credential sharing – driven by “scope-grained” policy rather than run-time opt-in consent Tested for suitability through trust elevation, e.g. step-up authn or “claims-based access control” (optionally using OIDC), captured in a specially powerful access token borne by the client Subsidiary access tokens protect UMA’s standardized endpoints and represent each party’s authorization (consent) to engage with the central server
    22. 22. © 2016 ForgeRock. All rights reserved.
    23. 23. © 2016 ForgeRock. All rights reserved. UMA technical vs. UMA legal • The UMA protocol can accommodate many “protected sharing scenarios” • The legal layer of trust relationships is in a parallel world where things can look markedly different • Parties map to UMA entities that interact “on the wire” • UMA is leveraging CommonAccord to create model text for accelerating “access federation” deployments
    24. 24. © 2016 ForgeRock. All rights reserved. Draft definitions from http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative/UMA-Text/
    25. 25. © 2016 ForgeRock. All rights reserved. Grantee Bob CO RSOASO UC1: Alice is an online adult with legal capacity • Her resources at the RS relate to her • So she is the Resource Subject • She controls access to those resources herself at the AS • So she is also the Grantor • She shares the resources with Bob • So he is a Grantee • More complication potentially to come here AS RS Grantor Alice = PAT C resource owner Alice requesting party Bob Resource Subject Alice AAT
    26. 26. © 2016 ForgeRock. All rights reserved. Grantee Bob CO RSOASO UC2: Alice is a guardian (proxy) for 2- year-old Johnny • His resources at the RS relate to him • So he is the Resource Subject • But she controls access to those resources at the AS • So she is the Grantor • She wants to share the resources with Bob on Johnny’s behalf • Johnny has no access because he is too young to do anything with them for now AS RS Grantor Alice C requesting party Bob Resource Subject Johnny AAT PAT resource owner Alice
    27. 27. © 2016 ForgeRock. All rights reserved. Grantee Susie CO RSOASO UC3: Alice oversees 12-year-old Susie’s online usage • Susie’s resources at the RS relate to her • So she is the Resource Subject • But Alice controls access to those resources at the AS • So she is the Grantor • Alice shares the resources in constrained fashion with Susie • So Susie is a Grantee • A narrow ecosystem would help for additional downstream controls to be in place • Susie will eventually turn 13 and will be able to control access to her own resources • Alice could be “kicked out” and Susie allowed to set up a direct AS relationship at that time, as a Grantor in her own right (see UC1) AS RS Grantor Alice C requesting party Susie Resource Subject Susie AAT PAT resource owner Alice
    28. 28. © 2016 ForgeRock. All rights reserved. Grantee Bob CO RSOASO UC4: Alice is offline and gives paper sharing directives to a government agency • Alice’s resources at the RS relate to her • So she is the Resource Subject • The agency controls access to those resources at the AS • It is the Grantor, by virtue of controlling a “headless” account for Alice for this purpose (see the NZ case study) • Alice specifies how to share resources with Bob etc. • The agency configures the AS for her • If Alice wants to take online control, the agency gives her a login to the account and steps out of the way • No more proxying – she would become her own Grantor (see UC1) AS RS Grantor Gov Agency C requesting party Bob Resource Subject Alice AAT PAT resource owner Gov agency
    29. 29. © 2016 ForgeRock. All rights reserved. Next challenge: model clauses enabling RSO liability management given AS instructions • The token says don’t give access: • When can the RS give access? • The token says give access: • When can the RS deny access? • Outside the UMA context: • When can RS give access? • Plus other juicy model text work: • What are the reporting and notification requirements? • How to enable jurisdictional and sectoral hooks? • How to handle three-party relationships (PAT and AAT)? • The same subtle split in the Requesting Party as in the Resource Owner
    30. 30. © 2016 ForgeRock. All rights reserved. Thank You

    ×