This protocol revision moves towards a more robust security model briefly described in #54, the first part of a slow migration towards integrating some of our oldest feedback in #4 having come full circle on OIDC, OAuth2, and back to asymmetric signatures for the entire Data Rights Request. This builds on the research that @kevinr has been developing with us and the partner companies over the last few months.
In short, the entire Data Rights Request submitted in POST /exercise will be wrapped in a signed body. For now that envelope will continue to be an RFC 7515 JWT, but we are evaluating a move to https://doc.libsodium.org/ in coming protocol revisions. The core of this diff is thus a signed data model of a flattened Data Rights Request described in section 2.02 wrapped in JWT signed by asymmetric keys
The up-shot of this data model is that all POST requests to the API eventually will be signed by a private key, and the "service directory" we have been mulling over can simply be a mapping of "authorized agent key id" (the kid parameter in POST /exercise) to the public key of the authorized agent, and there is no need for pair-wise API key exchange.
In line with work that @dazzaji is preparing for the initial "public" version of the system rules, i've taken some liberties to clarify the Identity Verification systems within the technical specification -- to say that we haven't actually spent much time on the dynamic need_user_verification flow and that the initial IDv pipeline will be much simpler.
There is a short list of work that needs to be addressed before a 0.6 is ready for full consideration:
[x] POST /revoke should be re-written to accept signed request
[x] GET /status authentication needs to be modeled, at least discussed. This is the major shortcoming of the signed data model in my eyes but maybe we can come up with a model that works for this. We could make this a POST but that doesn't feel "rest-y" but i am not sure i care.
These will be added before 0.6 is tagged:
[ ] timeline of Security Model to 0.7, 0.8, 1.0, etc
[ ] DRP network system rules
I did a pretty brash pass-through of this document and nipped-and-tucked some other confusing stuff like the distinction between the actors and the interfaces (#55)... i should have done this in a number of diffs, but stacking markdown diffs on github is worse than a visit to the dentist so this is what we get for the first revision.
This protocol revision moves towards a more robust security model briefly described in #54, the first part of a slow migration towards integrating some of our oldest feedback in #4 having come full circle on OIDC, OAuth2, and back to asymmetric signatures for the entire Data Rights Request. This builds on the research that @kevinr has been developing with us and the partner companies over the last few months.
In short, the entire Data Rights Request submitted in
POST /exercisewill be wrapped in a signed body. For now that envelope will continue to be an RFC 7515 JWT, but we are evaluating a move to https://doc.libsodium.org/ in coming protocol revisions. The core of this diff is thus a signed data model of a flattened Data Rights Request described in section 2.02 wrapped in JWT signed by asymmetric keysThe up-shot of this data model is that all
POSTrequests to the API eventually will be signed by a private key, and the "service directory" we have been mulling over can simply be a mapping of "authorized agent key id" (thekidparameter inPOST /exercise) to the public key of the authorized agent, and there is no need for pair-wise API key exchange.In line with work that @dazzaji is preparing for the initial "public" version of the system rules, i've taken some liberties to clarify the Identity Verification systems within the technical specification -- to say that we haven't actually spent much time on the dynamic
need_user_verificationflow and that the initial IDv pipeline will be much simpler.There is a short list of work that needs to be addressed before a 0.6 is ready for full consideration:
I plan to tackle these in this diff:
POST /revokeshould be re-written to accept signed requestGET /statusauthentication needs to be modeled, at least discussed. This is the major shortcoming of the signed data model in my eyes but maybe we can come up with a model that works for this. We could make this a POST but that doesn't feel "rest-y" but i am not sure i care.These will be added before 0.6 is tagged:
I did a pretty brash pass-through of this document and nipped-and-tucked some other confusing stuff like the distinction between the actors and the interfaces (#55)... i should have done this in a number of diffs, but stacking markdown diffs on github is worse than a visit to the dentist so this is what we get for the first revision.