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!
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:
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!