[Openid-specs-igov] Thoughts on additions to the iGov profile

[Mike Varley]

Hello all, 

I realize this might be a bit early for consideration, as we are still
gathering use cases and such, but I thought I would send it out to the
list for future consideration.

A common issue with broker based implementations (particularly in the
governments space) is during the exchange of attributes/UserInfo, the
broker may be exposed to the PII of the user. The following are some
existing OpenID Connect or JOSE specifications which may help protect the
user¹s data from inadvertent exposure (or tampering) that perhaps the iGov
profile could strongly recommend or require (for consideration).

1.  Support for UserInfo Distributed Claims (URL of claims data gets
returned, not the claims data itself. RP fetches data directly from the
listed sources)
    - helps with blinding the broker, as claims get fetched directly by
the client/relying party.


2. Encrypting user claims that go through a broker with (at least) 2 key
parts: a system generated key (OP system), and a User or UserAgent key.
(similar to key encryption with PBES2 as described in the JWA RFC section
4.8 [ https://tools.ietf.org/html/rfc7518#section-4.8 ] )
    - prevents eavesdropping on the encrypted data if one of the key parts
is exposed
    - ensures the user (or user's agent) is participating in the release
of the attributes at the RP
    - can also act as a second factor authentication if the user key is
delivered to the user out-of-band to an endpoint the OP has on record for
the user.

In addition to those existing mechanisms, we may want to consider some
additional functions.
I think it is very important to keep iGov as interoperable with other
profiles like HEART, but that being said, the following extensions may be
desirable for protecting user data when brokers get involved:

 
(A)  iGov may allow requests to specify the desired UserInfo encryption
key for an authorization session ­ like adding a Œkid¹ or JWK to the
request object that indicates UserInfo should be encrypted with the
provided public key.

     - clients can provide a public key for the session, and the client
may easily rotate its key to avoid being profiled by OPs (this helps blind
OPs from clients and vies-versa as there is no pre-registration of
encryption keys)

(B)  iGov may support a new field in the UserInfo object to support the
validation of the Distributed Claims; data claims can have an independent
verification endpoint to ensure the legitimacy of the claims data,
independent of the message signature.
    - as data transits the broker, the original signatures can get
stripped and replaced with Broker signatures. It may be desirable to
provide a verification endpoint the RP can compare the data against to
ensure it hasn¹t been tampered with. Something like a "_claim_signature {
}" structure


Just some food for thought; obviously the use cases will drive any outcome
of the above.

Thanks,

MV