[federation] introduce sector_identifier to OpenId Connect Federation

[Axel Nennker]

OIDC is discussing pairwise ids and how to compute them.  For several parties to have a common PPID a sector_identifier is used.

https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg

I am  wondering whether a sector_indentifier should be part of openid federation because is seems "natural" that the federating entities what a common PPID for a user.

Add a sector_indentifier added to an OpenId Federation?

‌

[gffletch]

Do we have any conformance tests for sector_identifier and PPIDs? Is this part of an existing certification profile?

[Michael Jones]

During the 22-Feb-24 working group call, Axel told us that this came up in the context of the Linux Foundation Camara Project Identity and Consent Management working group.

I remarked that it's OpenID Connect that creates subject identifiers - not OpenID Federation, and that the existing sector_identifier_uri could continue to be used as is. It's not clear that there's work needed to enable this in OpenID Federation.

[Vladimir Dzhuvinov]

OpenID Federation is the protocol that enables OPs and RPs to establish mutual trust. It is not really concerned with the nature of subject IDs in ID tokens, etc. This is in the domain of OIDC.

[Axel Nennker]

Although I here you and I agree, kind of, it still sounds to me that entities of a openid federation should have an easy way to get to a common ppid.

if the federation is not openid then I totally agree. Not a problem of the federation protocol.

Anyway, I think this can be closed.

Thanks for your thoughts. I am always glad that all the experts are in OIDF and I can get your insights.

Axel

[Axel Nennker]

don't fix. not a federation issue

[Vladimir Dzhuvinov]

Hi Axel,

A federation could enforce the issue of pairwise IDs with a policy like this:

"metadata_policy": {
  "openid_relying_party": {
     "subject_type": { "value": "pairwise" }
  },
  "openid_provider": {
     "subject_types_supported": { "value": ["pairwise"] }
  }
}

To enforce a common sector ID one could do this:

"metadata_policy": {
  "openid_relying_party": {
     "subject_type": { "value": "pairwise" },
     "sector_identifier_uri": { "value": "https://federation.example.com/sector-ids.json" }
  },
  "openid_provider": {
     "subject_types_supported": { "value": ["pairwise"] }
  }
}

OpenID Federation provides the policy tool. How it’s used for PPIDs is something for federation architects / admins to decide. Hope this helps.

[Axel Nennker]

thanks @Vladimir Dzhuvinov

Does one of you know if there are federations that do it this way?

[Axel Nennker]

How about adding the above example to https://openid.net/specs/openid-federation-1_0.html#name-metadata-policy ?

‌

[Vladimir Dzhuvinov]

I’m not aware of any such federations. There is only one in place now, the Italian IdP federation :)

About the metadata policy section, it’s currently getting one last redaction to clean up the language and give the operators precise definitions. The primary aim of the examples in the section is to give the reader a clear sense of how the policy language works, i.e. how the operators get applied to metadata parameters and the so called merge of policies when more than one Entity Statement has them in the Trust Chain. Illustrating use OIDC use case & best practises is not really an objective. I’ll see if there’s a good place to slip this in, maybe to demonstrate the working of the “value” operator.

[Vladimir Dzhuvinov]

@AxelNennker

I wrote a mini article in regard to sector_identifier_uri policy usage, because there is a slight snag in how OIDC requires this parameter to be verified. Something to take into account when creating a sector_identifier_uri policy at the top of a federation (in the trust anchor).

https://connect2id.com/blog/openid-federation-ppid-policy