Try Using the "Model System Rules and Participation Agreements" for City IdP Concept

dazzaji commented 9 years ago

Hi guys, Looks like you are making good progress and nearly ready to provide a legal framework for the technical demo of using OIDC via Wordpress to login to a City site. Especially since you want to model city as IdP and not just RP (we will leave "attribute provider to the side for the moment) it is time to look at the legal framework.

I offer this open framework to help get your started: https://github.com/HumanDynamics/SystemRules

i am adding this issue ticket to this repo requesting that you each look at the model legal rules and agreements for IdPs and others and consider how you would adopt-adapt it for use by a city as IdP. THis was developed for general use under Creative Commons license at MIT with the help of DARPA grant funding.

As a thought experiment try to adopt-adapt the model "system rules and participation agreements" for identity providers, individual account holders and other parties. This model is tuned precisely for OpenID Connect. To see a more "working example" customized to an enterprise use for it's own employees, check out the MITRE rules, at: https://github.com/mitreid-connect/trust-framework/blob/master/TrustFramework.md

This model is organized based on "services" such as an OpenPDS service providing a data store where individuals can store their data and allow permissioned access to it or allow questions to be posed to it such as "is this person over 18 years old?". It can also allow an OpenID Connect identity service (which was taken out of the final version because the DARPA project was focused on personal data sharing and not identity per se).

For an example of a model solely focused on OIDC for login and data sharing, see the implementation of this model by MITRE for use by all its employees (they have an "enterprise" deployment of OpenID Connect for their staff to use when logging into their own and external systems using their regular work ID): https://github.com/mitreid-connect/trust-framework/blob/master/TrustFramework.md

The point of organizing based on "services" is you can now have a city or other role agree to deploy a new or updated service and all you need to do is pop the service into the relevant section and the template causes a link to the roles, relationships, transactions and other system interdependencies needed to quickly assess what other rules of the system rules need to be updated to reflect and support the new service. A new or modified service provision of the rules may be for attribute exchange, login, data share, profile publishing, contract distribution, royalty distribution, etc. When thinking of a "roadmap" in a community of cities and other stakeholders in a "Trust Network" of City IdPs, it is critical to have a simple way for everybody to evaluate in advance proposed new services and the impact on value, rights, obligations or risk. How does it "change the deal". The deal has business, legal and technical dimensions. Each has a clearly marked section in the System Rules. Easy as pie. I love pie, by the way.

Anyway, scan the System Rules and start making edits to them. Don't worry about the PDF version. It is for show. Use the easy to deal with .md text format, for which you are welcome in advance. How do you start? Consider starting with a working version of the "Model" and seed it with a find-replace to customize for particular "parties" and "transactions" and "data". Those are the key "touchpoints" for applying model rules to specific factual scenarios. EG "KCMO" might be the "party" playing "role" of IdP.

Look at the Model System Rules like this - The document is a way to organize and write down as actionable contracts the arrangement of the parties, their transactions and the content of the transactions (the "payload" if you will) as well as other content (aka "data").

The Model System Rules provides you a quite easy and organized way to organize people, transactions and data like this:

Parties playing one or more role with relationships to one or more parties playing one or more roles in a system;
The transactions and other interactions each such party may conduct with other parties (via a service or other function of the system) in some way;
The data that is collected, stored, transmitted, used, etc in, with, through or arising out of the system.

What you have as a wrapper for all that is the "System". These are the rules of a system. If you want to circle up a bunch of cities to be IdP for the people you are definitely talking about a system. Could be a quasi public entity running a utility system. Could be a different type of system. But it is a system. You will need rules for it.

More to the point, you can design the system and describe it party (in large part actually) be defining the system rules that would apply to the prospective system. When you get all key parties to agree to prospective system rules in the form provided here, you have "a deal" that can be built (or just installed and configured with existing open source code) and deployed in very little time. The BLT and System Rules (role-transactions-data) approach to organizing services is for both "design" and agreement of new systems and works pretty well to evaluate existing systems and figure out what is really going on with them and how they work. You'd be using it for prospective design as part of a student project postulating a conceptual model for a multi-city IdP consortium. This is nearly at the center of the intended scenario of use for these system rules. Go to town with them.

Just fork the Human Dynamics System Rules repo, then Clone it to your desktop and then update the rules file (the .md file) in your directory (the one named "UMKC"). Then make a "pull request" so I can see your changes and I will do a "merge" that adopts your updates into the MIT repository. It is literally that simple. I will talk you through it on our hangout tomorrow if you have not mastered it by then. Or we can do it live on the hangout if you prefer. Either way - welcome to the big world of System Rules and GitHub law!

dazzaji commented 9 years ago

Here is your custom version: https://github.com/HumanDynamics/SystemRules/tree/master/Workshops/AcademicAffiliates/UMKC-CItyIdP-Concept

dazzaji commented 9 years ago

Here is the file where you would make updates and then "pull request" so we can take on your updates into the MIT Model System Rules: https://github.com/collabx/SystemRules

Please add the GitHub account usernames of any person (anyone you want to work with on the Online Legal Appathon project team) to this thread and I will give them access to the repository at https://github.com/collabx/SystemRules

(note: any one of you could have created this fork just by clicking the "fork me" button on upper right of the MIT repository). After the appathon, you may want to have a KCMO or UMKC or Code for America KCMO Brigade or other GitHub Org where you fork the System Rules code to do further work. But please use the collabx fork for now to get the hang of it. You can use the collabx fork a long as you want but it is designed to get things started and you may feel it too constrained when more collaborators - especially cities - get involves and want to work out admin and update rights in a more heavy duty way.

EvanAbsher commented 9 years ago

This awesome!! I'll dive in tonight!

dazzaji commented 9 years ago

You say "awesome!!" and I say "admin!!"

screen shot 2015-04-16 at 5 31 47 pm

dazzaji commented 9 years ago

Evan is now able to iterate the System Rules content here at CollabX. Any other takers?

\ Paul - No pressure, but wanted to highlight that while this may look legal and you may be thinking "this legal thing isn't really for me" please consider 2/3 of BLT and business and technical... some people spend a lot of time on the T in these BLT system rules docs and as a result have been known to co-create rather nifty systems in collaboration with their brothers and sisters of the B and the L. Just sayn'!

dazzaji commented 9 years ago

Incidentally... Evan Absher can now make Paul, Doug (or anybody else with a GitHub account) a team member with Admin rights or can make a team with only read-write access and add people to that. I don't technically have to do that function for this team anymore - but I certainly will do it at least for the remainder of the appathon if you wish it.

dazzaji commented 9 years ago

For a look at how OIDC services can be included as a distinct "service type" check out these outlined earlier draft version of the model system rules (listed as section header "1.3.2 'Federated Identity' services" in both drafts). The content that would appear under those draft in section 1.3.2 would be "business" oriented (because it is in section 1) and would cover basics like "service description, who owns and controls it, how much does it cost or how is price set, how operated, how managed, etc. Most detail about business, financial, operational, mgmt and other relevant section 1 topics would appear in external more detailed documents like "business terms" and "accounting practices" and "business processes" and "operating practices" and the like. These other docs are simply "incorporated by reference" into the higher level "system rules". The basic topics covered in the MITRE OIDC System Rules (dedicated solely to OIDC in that case in the enterprise-employee context) are good examples of some identity federation service items you'd expect to see. MITRE is for employees and so you don't see most of the stewardship and privacy terms included in the model (due to different business scenario and contexts of use - meaning the roles and transactions of the parties is different and hence different rules apply when the parties operate in the different context). MITRE has no concept of a Personal Data Store for their employees and so that service type is not included in the MITRE implementation of the model rules. You would just talk through the relevant services and include them in the service descriptions section of the postulated city IdP system.

EvanAbsher commented 9 years ago

Just to be clear. I am forking the rules in this link, https://github.com/HumanDynamics/SystemRules/blob/master/Workshops/AcademicAffiliates/UMKC-CItyIdP-Concept/Model_System_Rules-CityIdP.md, correct?

dazzaji commented 9 years ago

Already forked and in the collabx org as a forked repo and you are an admin with full rights to the forked repo.

| Sent from my iPhone | Please Forgive Typos

On Apr 17, 2015, at 10:39 AM, EvanAbsher notifications@github.com wrote:

Just to be clear. I am forking the rules in this link, https://github.com/HumanDynamics/SystemRules/blob/master/Workshops/AcademicAffiliates/UMKC-CItyIdP-Concept/Model_System_Rules-CityIdP.md, correct?

— Reply to this email directly or view it on GitHub.

EvanAbsher commented 9 years ago

Got it. I think I did the right thing.

collabx / IDASH

Try Using the "Model System Rules and Participation Agreements" for City IdP Concept #7