Difference between revisions of "OpenId Foundation Activities"

From IPEN Wiki
Jump to navigation Jump to search
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[File:Openid-r-logo-900x360.png|300x120px]]
[[File:Openid-r-logo-900x360.png|300x120px|Openid-r-logo-900x360.png]]


== <span style="font-size: larger;"></span> ==


== <span style="font-size: larger;"></span> ==
== <span style="font-size: larger;"></span> ==


== <span style="font-size: larger;">Introduction</span> ==
== <span style="font-size: larger;">Introduction</span> ==
Line 26: Line 22:
The HEART Working Group intends to harmonize and develop a set of privacy and security specifications that would enable an individual to manage the authorization, consent and release of their health related data via RESTful data sharing APIs, and to facilitate the development of interoperable implementations of these specifications by others<br/>List of current working documents / projects are as follows:
The HEART Working Group intends to harmonize and develop a set of privacy and security specifications that would enable an individual to manage the authorization, consent and release of their health related data via RESTful data sharing APIs, and to facilitate the development of interoperable implementations of these specifications by others<br/>List of current working documents / projects are as follows:


*Health Relationship Trust Profile for OpenID Connect 1.0
*Health Relationship Trust Profile for OpenID Connect 1.0
*Health Relationship Trust Profile for OAuth 2.0
*Health Relationship Trust Profile for OAuth 2.0
*Health Relationship Trust Profile for User Managed Access 1.0
*Health Relationship Trust Profile for User Managed Access 1.0
*Health Relationship Trust Profile for
*Health Relationship Trust Profile for
*Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes
*Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes


|-
|-
Line 45: Line 41:
|}
|}


=== <span style="font-size: 18.2520008087158px; line-height: 21.902400970459px;">Risc&nbsp;WG</span> ===
=== <span style="font-size: 18.2520008087158px; line-height: 21.902400970459px;">Shared Signals and Events WG</span> ===


{| border="1" cellspacing="1" cellpadding="1" style="line-height: 20.7999992370605px; width: 900px;"
{| border="1" cellspacing="1" cellpadding="1" style="line-height: 20.7999992370605px; width: 900px;"
|-
|-
| Chair
| Chair
| <br/>
|  
Annabelle Richard (Amazon), Atul Tulshibagwale (Google), Marius Scurtescu (Coinbase)
 
|-
|-
| Overview
| Overview
|  
|  
The goal of RISC is to provide data sharing schemas, privacy recommendations and protocols to:
The goal of the Shared Signals and Events Working Group is to enable the sharing of security events, state changes, and other signals between related and/or dependent systems in order to:
 
*Share information about important security events in order to thwart attackers from leveraging compromised accounts from one Service Provider to gain access to accounts on other Service Providers (mobile or web application developers and owners).
*Enable users and providers to coordinate in order to securely restore accounts following a compromise.
 
Internet accounts that use email addresses or phone numbers as the primary identifier for the account will be the initial focus.


The working group is currently gathering the requirements and fit and gaps. One of the topics that the WG appreciate is the privacy aspect of the sharing of the account data.<br/>In essence, the specification will be describing how to notify the relevant parties when higher account compromise risk were observed. For example, an email provider may provide that the email account now has elevated risk state that the service provider that uses the address as the account reset address may stop using it for the time being. This will prevent the account compromise chain among the service providers and will help maintain the user’s privacy.<br/>If the relationship between the email provider above and the service provider is explicit and the user has opted in, then it should not be a problem. However, in most cases, they are implicit. It is conceivable to guide the user to opt-in to this kind of relationship at the next login, but the people who did not opted in will not be protected. If the opt-out was allowed, the first thing the attacker would do after compromising the account is to opt-out from the account risk information sharing so that he can take over the related accounts as well. From our evaluation, one of the best way is for the service provider to share the password reset etc. email address with the email provider in bulk and set up the information sharing path without opt-out option. This will give the greatest privacy protection / privacy risk ratio.
#&nbsp;Manage access to resources and enforce access control restrictions across distributed services operating in a dynamic environment.
#Prevent malicious actors from leveraging compromises of accounts, devices, services, endpoints, or other principals or resources to gain unauthorized access to additional systems or resources.
#Enable users, administrators, and service providers to coordinate in order to detect and respond to incidents.


|-
|-
| Web pages
| Web pages
| [http://openid.net/wg/risc/ http://openid.net/wg/risc/]
| [https://openid.net/wg/sse/ https://openid.net/wg/sse/]
|-
|-
| Documentation
| Documentation

Latest revision as of 21:00, 28 April 2020

Openid-r-logo-900x360.png


Introduction

The objective of this page is to provide a high-level view of activities related to privacy standards in the OpenId foundation.http://openid.net/

"The OpenID Foundation (OIDF) promotes, protects and nurtures the OpenID community and technologies. The OpenID Foundation is a non-profit international standardization organization of individuals and companies committed to enabling, promoting and protecting OpenID technologies. Formed in June 2007, the foundation serves as a public trust organization representing the open community of developers, vendors, and users. OIDF assists the community by providing needed infrastructure and help in promoting and supporting expanded adoption of OpenID. This entails managing intellectual property and brand marks as well as fostering viral growth and global participation in the proliferation of OpenID."

Current working groups and projects related to privacy standards

Heart WG

Chair
Overview

The HEART Working Group intends to harmonize and develop a set of privacy and security specifications that would enable an individual to manage the authorization, consent and release of their health related data via RESTful data sharing APIs, and to facilitate the development of interoperable implementations of these specifications by others
List of current working documents / projects are as follows:

  • Health Relationship Trust Profile for OpenID Connect 1.0
  • Health Relationship Trust Profile for OAuth 2.0
  • Health Relationship Trust Profile for User Managed Access 1.0
  • Health Relationship Trust Profile for
  • Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes
Web pages http://openid.net/wg/heart/
Documentation
Comments


Shared Signals and Events WG

Chair

Annabelle Richard (Amazon), Atul Tulshibagwale (Google), Marius Scurtescu (Coinbase)

Overview

The goal of the Shared Signals and Events Working Group is to enable the sharing of security events, state changes, and other signals between related and/or dependent systems in order to:

  1.  Manage access to resources and enforce access control restrictions across distributed services operating in a dynamic environment.
  2. Prevent malicious actors from leveraging compromises of accounts, devices, services, endpoints, or other principals or resources to gain unauthorized access to additional systems or resources.
  3. Enable users, administrators, and service providers to coordinate in order to detect and respond to incidents.
Web pages https://openid.net/wg/sse/
Documentation
Comments


Retrieved from "https://ipen.trialog.com/?title=OpenId_Foundation_Activities&oldid=1371"