Are there any plans for aggregated/distributed claims support in hydra/oath keeper/fosite?
Please link the RFCs.
They’re optional parts of Core 1.0:
https://openid.net/specs/openid-connect-core-1_0.html#AggregatedDistributedClaims
Since you can set the claim values yourself in the ID token, this is already supported.
Great! The ability to set the _claim_names and _claim_sources is definitely necessary, but does Fosite support (and do hydra and oathkeeper implement) fetching the aggregated (hydra) and distributed (oathkeeper) claims from the additional claims providers listed in _claim_sources?
The agg/dist claims feature is needed in some federated environments where the IdP/OP isn’t the only entity that has claims they can attest to for the identity.
I might be wrong here, but isn’t this something the client must be capable of resolving? So for example, an ID token with claims
{
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"email": "[email protected]",
"birthdate": "0000-03-22",
"eye_color": "blue",
"_claim_names": {
"payment_info": "src1",
"shipping_address": "src1",
"credit_score": "src2"
},
"_claim_sources": {
"src1": {"endpoint":
"https://bank.example.com/claim_source"},
"src2": {"endpoint":
"https://creditagency.example.com/claims_here",
"access_token": "ksj3n283dke"}
}
}
is just that - a plain JWT object with those claims. The client consuming the ID Token (RP) has to resolve that then. That’s at least my understanding of it?
For aggregated claims, it’s the OP that gathers the claims; for distributed claims I guess I would (lazily, selfishly) hope that oathkeeper would gather the claims, although I’d understand the argument that that’s the wrong place to do it. (Fosite was the wrong choice to tag here in retrospect)
There’s not really a way to specify where that claim comes from (e.g. the JWT). In this case, I think relying on the extra session data within your consent app is the right move. The only thing we could help do is to construct the right payload but that’s about it.
Regarding distributed claims - an ID Token is a way to authenticate a user at a third party. It’s not a mean of authorization which is what the access token is doing. Therefore, I don’t think that Oathkeeper would be of any use here except for when it comes to /userinfo calls (which is currently not the case).
In general, the consent app & IdP don’t have access to these external claims sources, which is why for our project we need the OP to gather (some) of those claims initially; and we’re looking for an authenticating proxy to do the same for distributed claims on the RP end. I agree it’s not about authorization, it’s about marshaling the claims about the identity.
I’m not sure if I understand your use case. The consent app is just a delegation system for the OP. It has the same capabilities when it comes to claims and data as the OP. In fact, it is instrumented in a way which allows for specifically this use case where data is aggregated from various sources (e.g. Google Sign In).
A proxy (specifically first-party) does not solve authentication via ID Tokens. That’s just not what ID Tokens are made for. As I said previously, one legitimate area would be the /userinfo endpoint which can be queried using an access token. ID Tokens however are not something you send in the Authorization header of your API request. They do not have a scope, they do not have an audience (they do, but the intended audience is the RP, not the RS (resource server)) and they are not revokable.
Maybe I’m missing something in your specific use case, but I’m still not convinced that this is something that has to be solved in Oathkeeper or in Hydra - with the exception of the /userinfo endpoint in the case that we want to support aggregated/distributed claims there.