IAuth Project Page

March 26, 2013

Update: February 29, 2016: Pivotal Labs Tech Talk

An alpha version IAuth prototype was presented at the Pivotal Labs Monthly Tech Talk in Cambridge, Mass on February 29, 2016.  The code is available at: https://github.com/LegalComponents/IAuth (currently deploying to Heroku from the "auth_app" branch). 


Below is a brief technical demo:





Original Post: Announcing IAuth

The following draft is in it's initial "first cut" form and shared here solely for purposes of encouraging feedback and discussion.  Edited updates will be posted over the next several days and weeks.  The focus of below piece is on the IAuth and IdentityEmbassy approaches to identity and personal data sharing with business, legal and technical integrated architecture, rules and implementations.  However, the following piece includes more than one topic and may be edited into more than one post or article.


[Note Additional updates follow below the initial draft version 0.1 below]


March 26, 2013; Version 0.1


Solution Approach for Identity and Personal Data Sharing:

Prototype Development for Research Study Management


The eCitizen.MIT.edu research initiative of the MIT Human Dynamics Lab is collaborating on development of a prototype open source reference implementation of a generalizable platform to host apps and services enabling users to manage identity and personal data sharing by third parties according to the terms of user granted authorizations.   The prototype is being developed in collaboration with the MIT Consortium for Kerberos and Internet Trust and the Sensible-DTU research initiative of the Technical University of Denmark.  


Demonstrating IAuth & IdentityEmbassy Concept for User-Controlled Identity & Data Sharing via Integrated Legal & Technical Terms of Authorization


The prototype will apply, among other things, the general design principles, patterns and processes of IAuth and IdentityEmbassy projects of eCitizen.MIT.edu, collectively describing a method and structure for identity and data sharing systems through integrated business, legal and technical architecture, rules and unified individual account dashboards.  


The integrated architecture, rules and dashboard approaches will be focused to reflect context and achieve the objectives of the reference implementation scenario of use, namely:  Implementation of the Sensible-DTU web based platform hosted by a University for the purpose of providing researchers a re-usable set of services and code to access Android (FUNF) sensor data, Facebook, Google and camps WiFi data by permission of participants in computational social science studies.  The prototype reference implementation will reflect a series of requirements and constraints specifically related to the unique goals and project needs applicable to the Sensible-DTU project and it’s applicable policies, procedures, practices of the participating parties.   The design and development of the prototype reference implementation will, to the extent reasonably practicable, clearly and modularly group code, system flows, features and other functions that are unique to the scenario of use such that other reference implementations intended for operation in different contexts can easily modify, delete or replace inapplicable parts of the Sensible-DTU prototype reference implementation while re-using generalizable and context-neutral parts of the Sensible-DTU prototype reference implementation.  The prototype will be tested and evaluated against business, legal and technical requirements and performance criteria relevant to the context and use cases. 


About IAuth and IdentityEmbassy


The IAuth method and structure for business, legal & technical integrated architecture and system rules and the IdentityEmbassy user-dashboard and control surface for management of identity and personal data sharing user-granted permissions. 


The IAuth approach applies an architectural method and structure to otherwise standard and widely used web protocols for user grants of authorization to access their online resources.  The IAuth approach specifically involves defining the relevant underlying context and the supported use cases on three planes: business, legal and technical.  By articulating relevant requirements and interdependencies from the vantage point of each of these three key domains, it is possible to define and model a sufficiently complete and verifiably compliant statement of business, legal and technical use cases comprising a concept of operations for the services, apps and other components needed to launch and operate the system.



The IdentityEmbassy reference implementation provides simple and familiar user-account management design for the permissions and control over their identity and personal data management and sharing.  The control panel replaces the current practice of using legalistic Terms of Service with a shorter, simpler and familiar user account settings screen serving as a dynamic and partly user-controlled contract management control panel.  The control panel is comprised of a simple user account dashboard with unified display of current business relationships with services and apps including legal terms and technical permissions granted.  of user and service provider terms and of all parties authorized by the user to access the user’s identity or personal data, the scope of authority including constraints on types or ranges of data, limits on duration of time for which authorization is valid, links to other applicable contracts, and other relevant rights or obligations.  The “Terms of Authorization” provisions, in addition to being integrated within the user and service provider contract to provide a current accounting of all parties with access rights to the user’s personal and identity data, also supports user-controlled full revocation or in some cases modification for each grant of authorization.  Finally, the IdentityEmbassy supports user-control of authorization grant management across a number of different apps and services, affording the user a more powerful, efficient, effective and complete method for review and management of multiple connected accounts, permissions and administrative controls. 


Contextual Scenario of Use: Sensible-DTU Authorization and Informed Consent Service for Researchers and Study Participants


The basic scenario of use underpinning the development work is web-based management of research studies involving non-biomedical human subjects who, after providing informed consent, may participate as research subjects.  The "Sensible-DTU" intended platform for computational research studies enables an attractive solution for managing informed consent and providing study participants a simple web-based site to grant and manage permissions for access to their Facebook, Google and FUNF (Android sensor) data in one or more studies. 


This basic platform allows multiple researchers to host multiple studies on the platform rather than requiring each researcher to duplicate the effort. While the platform is designed to promote re-use of certain common functions and features for authorization services and permission management, the data itself resides with the apps or servers or the researchers.  This can be thought of an a very basic implementing the OAuth2 modular approach to authorization servers and resource servers.  While in practice it is very common for the authorization and resource access functionality to reside with one party and on one system, the design approach of IdentityEmbassy is greatly enhanced by leveraging the IETF OAuth2 standard method for separating each role. 


IAuth and IdentityEmbassy Generalizable Design Elements and Patterns


After the prototype for our research study scenario and use cases is running the following use-case adaptations and expansions for the platform will be for eConsumer/eCommerce and eCitizen/eGovernment.  The design patterns, however, remains basically the same even when applied to these other scenarios and use-cases.  The basic design pattern is a user-controlled simple dashboard and admin panel for managing identity federation and personal data sharing "grants of authorization" made by that user. 


The IAuth structural approach and corresponding methodology aligns, harmonizes and integrates the technical authorizations granted by that user with the legal authorizations granted by that user, thereby enabling a new approach to “terms of service” for personal data sharing.  Once harmonized, the terms of authorization can be displayed in an integrated way to the user (via a “dashboard”).   Even more importantly, with OAuth2, the authorizations granted by a user third parties for access to personal data, identity and other resources can be modified or revoked by action of the user.  This common feature of OAuth2 can be leveraged to exploit the vast untapped potential of the protocol to qualitatively transform the roles and relationships between users, resource providers and those granted third party access rights to the user’s resources. 


Transformational Potential of Aligning Business, Legal & Technical Facets


A new deal on data can be realized today by providing users the ability to grant, manage, modify and revoke permissions for sharing of their identity and personal data.  Remarkably, this revolutionary sounding vision can be achieved today without the need to invent new technology, or assuming companies and users will adopt new Internet protocols and standards, or requiring apps and services to support very different basic user flows and architectural design patterns.   In fact, this vision is achievable with just a slight adjustment to how existing information and options are presented to users.  Arranging and aligning relevant business, legal and technical facets of existing user flows and displays is all that’s needed.


The user-driven grant or revocation of authorization for access is the cornerstone of OAuth2.  The essential capability of user granted or revoked authorization for access to the user’s resources can be applied to address and transcend fundamental identity, personal data and privacy concerns and to realize the vision of an identity and personal data ecology.  It is individual identity and personal data that fuel the new crop of digital businesses operating in networked markets and comprising the emerging knowledge economy.  However, current barriers to widespread use of identity and data sharing prevent, delay, reduce and otherwise inhibit or skew transition to an information society.  The issues blocking adoption, use and reliance on identity and data sharing can be resolved by appropriately coordinated business, legal and technical application of existing and very broadly used Internet standards centered on OAuth2.


User Display and Dashboard View of Permissions Granted


It is already very common for OAuth2 enabled services to provide users an “Apps” page where a user can see up-to-the-second display of all permissions granted, including such facts as the identity of the parties permitted to access data, the period of time for which authorization has been granted, reference to each data type and resource description to which the authorizations apply, and so on.  Similarly, such pages provide users with the ability to revoke the active authorizations granted by the user to 3rd parties.  The widely used OAuth2 protocol is what makes such “Apps” pages, or other admin, preferences, profile, account or similar pages, possible.


IdentityEmbassy concept of a User Dashboard is not especially different in most practical ways from the typical “Apps” management pages noted above.  However, by deliberately aligning the display of this page with the business, legal and technical requirements established using the IAuth design and architecture elicitation,  requirements definition and consensus facilitation process. 


The Special Role of Business vis-à-vis Legal and Technical Domains


One important outcome of the BLT design methodology is the development of defined business dimensions of the system.  The business statement of requirements and capability descriptions can be expected to include the following types of topics:


business purpose/scope

business model/lines


business roles/relationships

business accounts/authorizations,


business services/capabilities

business transactions/accounting,


operations workflow/practices

operations changes/migration


operational performance/benchmarking

operations logging/audit



The business dimension is the initial aspect to be identified at least in rough general terms.  The legal and technical dimensions, while also critical and tied for first priority with respect to specification of the system architecture and rules and functions are nonetheless of secondary importance to the business dimension overall.  This is because the business aspects of the system reflect the executive level decision about what the system will do, for whom, and why.  Based upon those decisions, the legal and technical dimensions can supply further important details regarding “how” and can also add valuable contributions to various aspects of the what, when, and for whom the system will operate questions.


For example, if the business owners of a given system determine that the system will be used to compete in the mango type apps market but not orange type apps market then the legal and technical dimensions of the system would reflect and support mango apps and not orange apps, as would the business artifacts such as strategy, marketing and business plans etc.  The “B” comes first before L or T not only in the alphabet but also based on the importance of using legal and technical domains to accomplish the business outcomes of the organization or other group and not to fall prey to the backward process of running a business to serve the lawyers and technologists perspectives.  In some cases, there are deep interconnections and lines that are blurry at best between business, legal and technical domains, such as with a given business that may operate in a heavily regulated field or that may be designing a specific system, service or other product that exists for the primary or sole purpose of accomplishing a legal or a technical objective.  Nonetheless, the general rule that business comes before legal or technical holds true the vast majority of the time and is well deserving of a presumed position as the default primary and initial source of requirements and constraints for a given design and system. 


The Special Roles of Technical and Legal Domains vis-à-vis Business


While the business imperatives do indeed need to come first, it is notable that the legal and technical dimensions will very quickly take a nearly equal position with business once the design and implementation process gets underway and stabilizes.  For example, consider the following situation: The legal domain experts on the BLT design team for a given system could discover and contribute that certain Mango Apps must include a particular disclaimer conspicuously before sale, other Mango Apps may not be sold through the system on Sundays and other Mango Apps may never be sold to people under the age of 18. 


Ideally, in cases such as that above, unusual but materially important legal or technical requirements and constraints would be discovered through normal due diligence by the Business team early in the process, and not surfaced mid-way through the design process or worse yet after a system is launched and in operation.  Nonetheless, it is common that requirements or new and valuable ideas arise from business, legal and technical domain participants through the course of the BLT methodology of iterative design rounds and cross-functional reviews/comments loops.  This iterative contribution of requirements or constraints from each of the three key domains can be expected when the method is applied to design or deploy innovative identity federation or personal data consent-based sharing systems, party because such systems and lines of business are still relatively novel. 


The continuous tri-cameral issue spotting and resulting adaptive refinements by harmonized co-design is a strength and intentional feature of the BLT method.  The periodic cross-functional reviews between business, legal and technical groups not only serves to enhance the completeness and confirm validity of the architecture, rules and functional design, but it also enables a basis for defining and aligning the otherwise frequently sub-optimally coordinated activities of business, legal and technical participants on a given system design, launch, operation or migration team.  Once aligned, the business, legal and technical facets of a design can be harmonized, including by measures potentially including: Explicitly cross-referencing between business, legal and technical rules or other normative documents and records when an important interdependency is discovered or established; Choosing a unified set of definitions for constituent use; and Using the same base-set of Use Cases for core service, transaction and other interaction diagrams to ensure non-conflicting starting assumptions and future drift between the three key domains use and assumptions about purpose and context for any given part of the system.  \


Systemic Integration of Business, Legal & Technical Governance


According to the BLT governance and operations method, if or when a given participant desired to modify a use case, then the next step would be to have the domain committee that owns that use case (business, legal or technical) agree to recommend the updated use case, and then the other two committees would review/comment upon the proposal, and if there was a consensus, then a unanimous recommendation to adopt the change would be proposed to the governing body for the system and finally, if the proposal was accepted, then the update would be published and would become a formal amendment to the system rules and architecture, etc as of a given future date. 


In the case of a material change proposed by one domain group, it is likely that the corresponding use cases of the other two committees would also need to be modified to remain in sync, and also that other rules, architectural elements, policies, procedures or other aspects of the system may need to be modified to support the proposed change in a use case, and the ongoing tri-cameral BLT governance groups are intended to surface such interdependencies as an essential part of their charters and missions, and to note the issues, propose solutions if possible and share any comments or recommendations on the advisability, risks and trade-offs associated with pursuing the various options that may emerge. 


Electronic Contracting Practices Are Insufficient at Best


While the BLT method is effective and valuable in a business to business context, it also holds a special potential when applied to the IAuth and IdentityEmbassy approaches for use by individuals with respect to their own identity and personal data sharing and other online transactions or commercials contracts.  This is because the method and architectural approach can directly unwind one of the core dilemmas holding back realization of full value from online transactions: Namely, a workable solutions for individually controlled sharing of identity and personal data. And not just any workable solution, but a solution that is sufficiently better for each stakeholder in today’s marketplace and also opens the way to truly innovative new markets and business models of the future.   The current situation with online contracts and authorization is woefully inadequate to the task. 


Contract law traditionally assumes an underlying context and scenario of parties with sufficiently comparable bargaining power to negotiate and come to an eventual meeting of the minds on a final agreement.   While many variants of contract exist, it must be noted that today’s common scenario of use with individual’s is almost unrecognizable from the assumed conditions for a contract and on very dubious foundations.  Contracts, unlike other assertions, agreements or promises, entitles a party to hold another party to the contract, if necessary, through focused use of the power of the state.  Government can and in some situations must enforce conformance with contractual terms, through the judicial system and culminating in targeted deployment of law enforcement to compel compliance including by use of physical force if necessary.  Enforcement of contracts under the law is a serious matter that must be founded upon proportional and reasonable premises. 


Today, there is an accepted underlying implied scenario whereby the individual user has no possibility of negotiating or even influencing any term to be included in a contract for an online service or an app, and can not reasonably be expected to read or understand the applicable terms.  Individuals frequently can not save, access or manage the contracts of adhesion imposed upon them through their computers and phones, much less seek to amend the terms later. 


Full Circle: Contracts Reflecting Actual Agreements as Mutually Amended Periodically


The IAuth and IdentityEmbassy approaches directly address the need to improve electronic contracting practices online.  The functional capabilities available for the user to access real-time display and review the terms of authorization, when combined with the functional capability to manage, revoke, limit or augment each grant of authorization results in an electronic contract that is dynamic and capable of being changed in important ways by the individual.  The individual, based upon facts and circumstances at that time, can choose to add parties and permissions within a given agreement, as reflected under the Terms of Authorization section, or to modify or revoke certain permissions or to terminate the permissions for and link to a given third party all together.  This is, again, a basic property of the intended application of OAuth2. 


This basic property is also revolutionary. The revolution this reflects took place hundreds of years ago, establishing the rights and obligations of free people under a post enlightenment and Magna Carta inspired social compact, within economic open markets and under political systems of self governance enshrining civil liberties and individual sovereignty to consent as a condition and prerequisite to being governed.  This vision was indeed revolutionary.  We won the revolution.  And today, the most common online architectures and flows sometimes seem to more closely resemble the kind of system that would exist if the oligarchs, kings and warlords had prevailed rather than free people operating in open markets.  The remarkable power of the OAuth2 quintessential assumption that individuals must explicitly assent to grant authorization to a party as a condition precedent to that party gaining access to the individual’s resource is at once seriously simple, profoundly powerful and beguilingly beautiful. 


The IAuth and IdentityEmbassy approaches carries the OAuth2 quantum design pattern of user granted authorization for access to that user’s resources all the way through the user and third party data sharing relationship life cycle from  negotiation, formation, management, amendment and termination.  The process of reviewing the Terms of Auth, using the IAuth approach, becomes a plausible task for a regular person with a normal amount of time and interest in review of such terms – and for most people this amounts to nearly no time, attention or energy being available to scrutinize and deliberate about the specific technical and legal and business dimensions related to granting sharing access.  This is why IAuth and the IdentityEmbassy approach enables people to make reasonable judgment on rapid basis or in some cases intently upon glancing the material terms and rating of a given third party regarding a given service or app and scope of personal data or identity sharing. 


After forming a new link or integration with a third party service, the user has a genuine control panel enabling autonomous choice to grant, modify or revoke authorization to access personal data or identity.  While currently, even a robust implementation of IAuth and IdentityEmbassy would be a substantial improvement over the existing tangle of dense and all-but unseen functionally invisible terms, even so, the real difference for these approaches is achieved when constellations of service providers and app developers support some of all of the core functions and interfaces of the IAuth and IdentityEmbassy approaches.  At that point, as can be seen with respect to FUNF integration with the intended Prototype Reference Implementation, the legal and technical rights and obligations can be harmonized elegantly with the business context, including the value, nature of the relationship (department to citizen, retail store to consumer, training course to student, social network to user, non-profit to member, etc).  The overall set of legal code and corresponding technical code is profoundly different from the current consumer electronic contracting practices.  The existing approach to Terms of Service results in dense legal textual documents that neither inform nor enable users to manage rights and obligations related to their personal data or identity.  In reality, only rarely do users see much less save the content of Terms of Service contracts they purportedly agree to and that are intended to be enforceable against them.  By contrast, the IAuth method provides more transparency, choice and control for individuals with respect to the sharing of their personal data and identity. 


Summary and Vision for Future State


By carefully structuring the IAuth and IdentityEmbassy project to directly reflect and support exactly the current common approaches and implementations of the OAuth2 protocol, this project is intended to provide a solid foundation for wide adoption in a variety of contexts.  The project is also intended to be easy for app makers and developers of online services to understand, work with and innovate upon the foundational architecture and design pattern.  The alignment and integration of business, legal and technical facets of user granted authorization management forms a clear architectural foundation.  This architecture is a reliable basis for building apps and services that rely upon predictable access to and use of personal, sensitive, private, confidential, secret or otherwise protected information that may be validly shared by consent or other such authorization.  The BLT architecture is a sound basis for innovation partly because it clearly provides a method and structure for adding new components and services to a system.  Beyond the efficient support for adding new services and components, the BLT architecture also provides simple processes for expanding, extending, reducing, removing or otherwise modifying or evolving existing components and services. 


By applying, as intended by the explicit provisions of the technical protocol, this little understood but widely adopted user permission function of OAuth2, it is possible to access the extraordinary power and potential of personal data and identity sharing across economic, jurisdictional and networked or other systemic boundaries.  The unleashing of permission-based personal data and identity sharing allows otherwise impossible personalization and informational services for individuals and naturally enables exponentially more powerful uses of big data for organizations.


Update: July 15, 2014:  

The following posts on Google+ are part of the recent focus on discussing the IAuth design pattern and encouraging people working on relevant issues to take a closer look.  The full post is available at: https://plus.google.com/106335924806014570758/posts/FBPcYUc1dwo  

Dazza Greenwood

Shared publicly  -  1:39 AM

The openPDS software is one of the types of capabilities that will enable big data and personal data to travel on the same highways without crashing into each other.   

>>  Read all about it...


Benjamin Wright10:29 AM

The press announcement above says, "Today, he says, "when you install an application, it tells you ‘this application has access to your fine-grained GPS location,’ or it ‘has access to your SD card.’ You as a user have absolutely no way of knowing what that means. The permissions don’t tell you anything.”" I agree, with a reservation.

One factor does hold app-maker's feet to the fire is public discussion and public opinion. If an app-maker is over-reaching and abusing data, then it runs the risk that a vigilante researcher (or whistle blower) will discover the infraction and publish it. 

A vigilante researcher caused much grief for Carrier IQ; eventually Carrier IQ reformed its data practices. http://www.engadget.com/2012/05/09/carrier-iq-hires-former-verizon-privacy-counsel-magnolia-mobley/


Dazza Greenwood8:32 PM  

Great point, Ben.  To make your point more explicit, IF there are permissions granted then there is a basis upon which to determine whether a party is "over-reaching and abusing data" because one can refer to the permissions actually authorized and ask if the later conduct of the party is in the scope what the individual permitted... or not.  The practices are now, with permissions, at least observable and hence, as you point out, a research/investigation can reveal major problems in some cases.

But what if those same permissions could be used to reverse the situation and not only as a starting basis for a potential long-shot that a vigilante researcher or whistle blower might discover, work on and find success shining light upon the situation?  Let's face it, hoping for a vigilante researcher (or whistle blower) is not an especially reliable, effective or minimally adequate plan.  The MIT Human Dynamics Lab has developed a way to use these same permissions to form a simple and small action intended to result in a solid and scalable solution to the problem.  

Consider this: The "touch-point" between a person acting as an individual consumer and an app (ie the legal party behind the software such as a an app "developer" or a company that distributes an app to make it easier to do business with them, etc) sometimes provides MUCH more information about the precise nature and scope of permissions granted.  When the permissions are made through the basic web-flow of OAuth 2 (which is the most common and perhaps nearly universal method) then we have, be design, created and preserved evidence of precisely the information needed for each of the three key parties in the scenario to demonstrate whether they were acting properly.  

The three basic party types are 1) the individual (the person who, acting in their private personal capacity and not on behalf of a business or other entity, is using an app and granting permissions to that app), 2) the app provider (the party who is responsible for the app that has requested access to some otherwise unaccessible personal data or other protected resource of the individual) and 3) the protected resource host/provider (eg your calendar, your contacts, your geolocation, your travel itinerary, your photos, your financial information, your shared notes, etc).  Let us call these the "Three Roles" of this "Scenario" and these are indeed the three typical roles involved.  

Technically (but oversimplified for quick/easy ingestion) what is happening is use of OAuth 2 protocol enabling the user to grant permission to a third party app to do something with secure information (aka "protected resources")  of the user.  Example general permissions might be some type of authorization to access or read-only, or to add, modify and/or delete protected resource data or some other authorized function or flow.  

Functions and workflow or approval chain type grants of authorization other than add/modify/delete might include permission to discover when the protected data is modified and to send an alert or it could be to enable an integrated transaction flow for any purchase above or below a defined amount of money, etc.  

These are called "Scopes of Authorization" and every OAuth 2 enabled grant of permission by an individual user for an app to access and do something with a protected resource necessarily operates according to one or more of these "scopes".  

If you are thinking (as a lawyer) "hey, isn't this important?  what are these scopes again?  how many are there?  can i see some?  how we we audit them and do reports to understand which scopes are being used by which users? how do we know whether the limitations or requirements enumerated in the scope are or are not being performed?  how do these scopes of authorization relate to the terms and conditions of the contracts and licenses between the same parties?  what is the place of these scopes of authorization in the basic definition of the roles and relationships of and among the parties (ie the individual and inter-party functions, expectations and duties including their applicable rights, responsibilities, requirements, recourse and remedies)?" ... these are good questions.  

The project called "IAuth" here at the MIT Human Dynamics Lab where I am a legal-oriented scientist was focused on simple design patterns and working example prototypes demonstrating exactly how we can clarify and frankly largely solve many core so-called "privacy" issues by explicitly conforming business, legal and technical practices to integrate these grants by individuals of OAuth 2 scopes of authorization for apps to access/act upon their private/protected data into the business relationships/value propositions, the legal agreements/terms of use and the technical integrations and data flow/authorization systems.  

So... yes, i believe your insight that the permissions granted by people are a relevant point of intersection upon which much progress can be made is a great point and can be leveraged to reduce the "permissions don't tell you anything" blight and actually reverse the situation to enable the permissions to be the anchor-point that tell you precisely who all parties are with enumerated types of authorizations to the personal data and other protected resources of individuals.  

This is available today with virtually no new technology or system or platform or services.  Simply by configuring and integrating OAuth 2 existing widely (perhaps almost universally used) protocols this is achievable today.  

Specifically, the IAuth approach demonstrates how to leverage the scopes of authorization by listing the permissions granted clearly and cross-linking scopes from and to the relevant provisions of contracts.  This information provides a fuller picture of all the parties with access to a person's protected resources (private data) and can be presented directly on the account pages or "apps management" panels that web sites already provide for people to get a view of their current situation with the company (billing relationship, permissions, integrated apps, etc).  

This means it is possible to have the basic business deal (the value proposition) and business transactions from the view of each party aligned, harmonized and literally integrated with the legal and technical dimensions of the roles and relationships of all the parties to this common scenario of web based commerce and transactional permission access to identity and protected data.  

By use of this IAuth approach to existing technical and business methods it is possible to transform permissions confusion that create violations for privacy, consumer fraud and information security into new deal on data ensuring appropriate individual comprehension, consent and controls over their own identity and personal data.

Using the IAuth way to offer the globally used OAuth 2 based individual permissions, we can reverse the sad situation that "You as a user have absolutely no way of knowing what that means. The permissions don’t tell you anything."      

More info at: http://ecitizen.mit.edu/iauth-project  and the (somewhat stale now) blog: http://iauth.org/


Update: June 2, 2014:

As the Legal Physics research agenda comes together, the IAuth design pattern is being revisited for further development.  In the time since the posting of the conceptual outline (published below on March 26, 2013) our research team has developed related legal and technical aspects of the IAuth vision.  The ClearButton Project, proposed an architecture that more directly includes the other key parties to IAuth scenarios: 1) identity and personal data service providers and 2) third parties who access and/or rely upon individual identity information and other personal data.  Also, work has advanced on data structure, format and service composition of relevant legal provisions of statutes, regulations and other overarching rules.  Work iterating the UMA Binding Obligations specification has provided another avenue to advance the IAuth concept.  IAuth related content is being collected from the former project site IAuth.org and other sources to develop further by the Legal Research team at the Human Dynamics Lab.  Questions, comments or ideas about IAuth are welcome and may be posed at our contact page.  -- Dazza Greenwood, MIT.