[Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text

Axel.Nennker at telekom.de Axel.Nennker at telekom.de
Mon Jun 12 08:36:22 UTC 2017


I agree but I think this is not a problem that CIBA has.

In front-channel you have the same problem at registration time: How does the OP verify that the siu and the redirect_url are valid and not already 'taken' by good.com ?
If malware.org is able to register its redirect_uri for an existing siu then the system is broken.
Nothing new for CIBA here!

When a Client registers for CIBA then the current spec demands that a siu is registered and validated at registration time.
If the Client wants notification then the Client MUST register a notification callback uri.
If the Client wants to sign something then the Client MUST register a jwks_uri.
The Client is authenticated in all CIBA requests using some method specified in OpenID.core.

OpenID.Core does not specify who discovery and registration works but refers to the OpenID.Discovery and OpenID.Registration specs.
https://openid.net/specs/openid-connect-core-1_0.html#DiscoReg

Why should CIBa talk about discovery and registration? Like in the example from OpenID.Core-Section-DiscoReg an OP might have pre-configured relationships for CIBA-using Clients. Then all client metadata like siu etc are fixed when the contract between Client and OP is signed.

// Axel


From: Manger, James [mailto:James.H.Manger at team.telstra.com]
Sent: Freitag, 9. Juni 2017 11:03
To: ve7jtb at ve7jtb.com; openid-specs-mobile-profile at lists.openid.net; Nennker, Axel <Axel.Nennker at telekom.de>
Subject: RE: [Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text

Axel,
What is stopping my CIBA client (malware.org) from registering your siu (https://good.com/sector.json) and, hence, being given your subs when users sign-in to my app?
Nothing, unless the OP checks that https://malware.org/notify is listed in https://good.com/sector.json and rejects my app when this isn't the case.
--
James Manger

________________________________
From: Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de> <Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de>>
Sent: Friday, June 9, 2017 6:53:11 PM
To: Manger, James; ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>; openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Subject: RE: [Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text

Using the example from http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation

The siu is https://other.example.net/file_of_redirect_uris.json
And in the context of pairwise identifier algorithms the content of that file is irrelevant because what feeds into that algorithm for all clients in that group is exactly "other.example.net" and nothing else.
That is
  sector_identifier === "other.example.net"
in https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg

This value of sector_identifier does not change whether the Client uses Polling or Notification or needs a jwks or not.

I think that these are separate topics.

CIBA demands a sector_identifier_uri to enable pairwise subs and I still don't see why this topic is related to whether the Client polls or uses notification or signed somethings.
If the CIBA Client wants to be notified then it _additionally_ needs to  specify a notification_endpoint_url at registration time.
If the CIBA Client wants to sign something then it _additionally_ needs to specify a jwks_url.

If CIBA would not have sector_identifier_uri being mandatory at registration time then CIBA would need to talk about _default_ values for sector_identifier_uri.


// Axel


From: Manger, James [mailto:James.H.Manger at team.telstra.com]
Sent: Freitag, 9. Juni 2017 02:02
To: Nennker, Axel <Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de>>; ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>; openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Subject: RE: [Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text

> My hope was that by making sector_identifier_uri mandatory we would get rid of all the special cases with jwks_uri and whatnot.
> Isn't that true?

No.

> So if someuses CIBA then there MUST be a siu at registration time and CIBA does not care how that is validated.
> Making my life too easy?

Wishful thinking, Axel ;)


An OP needs proof that an app is entitled to use a sector_id before revealing the subs associated with that sector_id.
A new app merely quoting a sector_id in its registration is not proof. It shows the app wants that sector_id, but it doesn't show that the other apps using that sector_id want to share subs with this new app. It doesn't prevent a malicious app quoting another group's sector_id.

So the content at a sector_identifier_uri needs to identity each app that is entitled to use that sector_id (host part of siu). It does so by listing a URI that each app needs to control to operate. For "normal" OIDC an app's redirect_uri is sufficient; for CIBA with notifications an app's client_notification_endpoint is sufficient; for CIBA with polling and asymmetric signatures an app's jwks_uri is sufficient; for other cases the tuple {iss, client_id} could work.

Hence CIBA needs to add that, at registration, the OP needs to confirm that siu lists client_notification_endpoint (to enabling notifications) or jwks_uri (to enabling polling with asym sigs).

--
James Manger


From: John Bradley [mailto:ve7jtb at ve7jtb.com]
Sent: Donnerstag, 8. Juni 2017 18:56
To: Nennker, Axel <Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de>>
Cc: openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Subject: Re: [Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text

Validation of the sector identifier is part of registration.

The client registers its client_notification_endpoint as a new element.  (Shouldn't that be an array vs a single URI if the request allows notification_uri to be specified?  otherwise why send it in the request?)

The registration process needs to check those URI against the URI in the JSON file returned from the sector_identifier_uri.

I dont think registration is going to get updated anytime soon so it probably needs to be explained in this spec for those IDP that allow notifiction_uri to be specified.

All AS should always use the sector_identifier_uri as the key for generating ppid. Nothing in that changes.

I think for the polling we need to specify the client JWKS endpoint in the sector_identifier_uri as well.

It is just a URI so that should not be an issue.

If the registered jwks uri is not in the file then don't allow polling.
I know this precludes the use of symmetric keys but I think that may be a reasonable trade off if someone wants to use this with polling.

John B.



On Jun 8, 2017, at 3:38 AM, <Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de>> <Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de>> wrote:

Hi all,

can this issue be closed?
https://bitbucket.org/openid/mobile/issues/52/ciba-pairwise-identifiers-structuring-text

The sector_identifier_url is now mandatory to be specified at Client registration time.
Validation of the sector_identifier is out-of-scope for CIBA and should be in Discovery.

Please comment on the issue in bitbucket or here.

Kind regards
Axel





DEUTSCHE TELEKOM AG
T-Labs (Research & Innovation)
Axel Nennker
Winterfeldtstr. 21, 10781 Berlin
+491702275312 (Tel.)
E-Mail: axel.nennker at telekom.de<mailto:axel.nennker at telekom.de>



_______________________________________________
Openid-specs-mobile-profile mailing list
Openid-specs-mobile-profile at lists.openid.net<mailto:Openid-specs-mobile-profile at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170612/aeb20665/attachment-0001.html>


More information about the Openid-specs-mobile-profile mailing list