[Technical_wg] how to solve distributed claims
pawel.kowalik at 1und1.de
Mon Oct 8 11:18:43 UTC 2018
To answer the first question: no, there should not be any issue @ Agent
if access_token for distributed claims is different to access token issued towards Authority.
RP implementations can show issue if not accounting for different access_token.
When experimenting recently with encryption settings (setting id_token_encrypted_response_alg
and userinfo_encrypted_response_alg during client registration, together with jwks) I noticed few issues/inconsequences
which pay into this discussion as well.
1. access_token, as received from Identity Authority, is not encrypted. It does not contain any user's private data,
but still there should be a way to enforce encryption here. When we do that, access token for the Agent
must be encrypted with Agent's public keys, automatically being unique for the Agent (or distributed
claims provider in general sense)
2. User info and id_token coming from Authority are encrypted as expected
3. User info coming from Agent is not encrypted! This one is more critical and would require Access Token also to contain either jwks_uri or jwks of the RP,
same as used during client registration, so that Agent could encrypt the response. OIDC is silent about that part .
4. there is also one small glitch in OIDC spec regarding distributed claims, as there is only user-info endpoint provided, not really "iss", so finding Agent's
keys to verify JWS is kind of guesswork (one needs to assume that /userinfo has openid configuration at the same domain, or use id4me data from DNS record,
which would work for us, but does not for OIDC). Would be better to have iss there instead, as it contains /userinfo in openid configuration anyway.
For me 1&3 would be points to add to the to-do list.
From: Technical_wg [mailto:technical_wg-bounces at lists.id4me.org] On Behalf Of Marcos Sanz
Sent: 10 September 2018 16:35
To: Peter Höbel <peter.hoebel at open-xchange.com>
Cc: technical_wg at lists.id4me.org
Subject: Re: [Technical_wg] how to solve distributed claims
> >>> We are thus considering to make a distinction between the
> >>> delivered by the Token Endpoint and the one(s) delivered by the
> > UserInfo
> >>> Endpoint, still both being self-contained JWTs. Peter, Pawel: do
> I expect no problems with this by the relying party api.
> Do we have a test environment for that topic - some identity
> authority/agent combination, which provides different access token?
we'll put up something like that. Thanks for the suggestion.
> > see
> >>> possible disruption at your sides of the prototype?
> >>> In any case, thank you for the interesting discussion!
> >> If a single token is issued for use at multiple resources which
> > to different entities, or you generally want to bar replay,
> >> there are 2 ways to prevent replay :
> >> 1. Bind the token to a client certificate that belongs to the RP.
> > is specced in the MTLS draft which we implemented last year
> >> for the FAPI sec profile. Unfortunately this solution complicates
> >> the
> > client side code somewhat, but I find it quite elegant
> >> otherwise. The bearer weakness of access tokens is thus fixed
> > https://tools.ietf.org/html/draft-ietf-oauth-mtls-11
> > I took a look at it, and indeed, it's pretty elegant and even solves
> > misuse scenarios.
> > This is hard for me to say, but complicating the situation for
> > clients
> > the last thing we'd like to do at this stage of the project... :-/
> > Best,
> > Marcos
> >> 2. Issue identifier based access tokens which require introspection
> > well as the resource server authenticating. Each resource
> >> server is then presented with only that token information which is
> > for them. It doesn't need to know what other claims have
> >> been consented, a plus for privacy.
> >> Vladimir
> > _______________________________________________
> > Technical_wg mailing list
> > Technical_wg at lists.id4me.org
> > https://lists.id4me.org/cgi-bin/mailman/listinfo/technical_wg
> Peter Hoebel
> Senior Developer
> Cell: +49 176 702 686 04
> Phone: +49 2761 75252 00 Fax: +49 2761 75252 30
> Email: peter.hoebel at open-xchange.com
> Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court
Nuremberg HRB 24738
> Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Uwe Reumuth
> Chairman of the Board: Richard Seibt
> European Office:
> Open-Xchange AG, Hohenzollernring 72, 50672 Cologne, District Court
Cologne HRB 95366
> Managing Directors: Frank Hoberg, Martin Kauss
> US Office:
> Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA
> Technical_wg mailing list
> Technical_wg at lists.id4me.org
Technical_wg mailing list
Technical_wg at lists.id4me.org
More information about the Technical_wg