[Openid-specs-ab] Connect WG meeting notes - 22 Feb 2024

[Pamela Dingle]

OpenID Connect Weekly Meeting Notes

Date: 22 Feb 2024

Attending: G. Fletcher, M. Jones, B. Campbell, P. Dingle. A Nennker, B. Helm

Scribe:  P. Dingle


Official business:


Issue filed by Axel: https://bitbucket.org/openid/connect/issues/2118/federation-introduce-sector_identifier-to


Mike - Federation has no subject identifiers, so how would a sector identifier be represented in the opened federation spec?

Axel - We have a ton of operators, such as company subsidiaries that have a common infrastructure, but also have hyper scalars and other more distanced entities, so how to come to a PPID.


Pam - could this be about specifying in metadata how the subject identifier is constructed

Alex - maybe, maybe you could specify PPID_enum in Connect and then fill that with the needed method for the sector identifier?

Mike - we have defined that for dynamic client registration, could that value be re-used?

Alex - maybe, will go look.

Action: Mike and George to add context to the issue.


Beginning of meeting was freeform conversation


Question from George - how to structure representation of specific policy satisfaction “step-up” in OpenID Connect


  *   Insufficiency needs to be represented - how does it say what is required back to the AS?
  *   9470 says “I need a new authorization”, but what is the semantics of the RS saying “This is the policy chain that you need to follow to get there”


Scope could be overloaded, ie “urn:somepolicychain” but it isn’t exactly what we need

  *   Could we add a policy element to the WWW response?


Question from Mike: how does this related to the RAR spec?

  *   9470 is unlikely to contain PII where as RAR


Pam - this also relates to SSF/CAEP, we have a requirement to potentially inform RS’s of simple policies to be  enforced


Brian - Also important to ask how much action can the client even take to remediate that situation.  This is why RFC 9470 stayed very tight in scope, as soon as you get into specific policies, it becomes very unclear how entities should enforce those policies.


George - RS says to client 1 “I need a steppe but I only accept passkeys” but to  client 2  it has different requirements.  How do you implement that kind of complexity.   Could have cases where



George - most amrs result in a possession factor - we’ve lost the “something you know”. - if all your password


>From a threat perspective, if I have the device then I have both the factors.  There are also cases where you can only have a knowledge


Two levels - technical agreement on what it means to send a push notification to an app etc and what are the nuances.  But 2nd, should there be an assignment of those classification mechanisms to higher level guidance.  Also are there other core level qualities of the authentication methods that could be technically agreed on


Mike - noted a comment from Brian that we need to keep the scope of the protocol on what can be evaluated within the operation of the protocol


Pam - we need to decide where the line is between what we can safely represent in the protocol vs. what needs to go into an official “authorization” specification


Brian- that was the original idea behind authorization context, we created identifiers that represent policies,


George - agree but there is so much now that policies need to encompass, there are many more pieces.  If ACR should be “the policy that is needed for the request” and there is some URN or URI,  that feels like extending the spec too far.


Brian - it gets way more murky when we start talking about what is out of control of the user, for example the requirement for admin roles - if the user is an admin there is no actual action the user can take to get access at the time of authentication.


George - agree, we shouldn’t even initiate step up if there is no way a user can ever accomplish what is needed.  It is better to return an error that is effectively “access denied” .


Pam - maybe there is a new thing beside access denied — these days there is accept, deny, redirect to honeypot, redirect and detect/signal risk


George - probably couldn’t be in scope of stepup,  it would need to be an out-of-band call via shared signals to say “Hey I’m sending a client back to you, but you should deny it”


Axel - we are interested in how we could convey policy to a resource server, such that the RS only delivers functionality to  clients that are on the mobile network.   ACR works for this to represent the 80% use cases,  and then we extend to include IP address ranges etc using a policy description language that has and/or but not NOT. If you add too much then the language explodes.  People can never agree on legislation and jurisdictions.   This is not totally a technical problem, solving the most important cases can be done, defining all cases blows up.  Consent is also a huge problem, nobody can agree and may not be able to be solved by technical means.


Pam - do folks think this can be defined?   Should we try (seemed to be consensus that we should try)


George- you could have a step-up requirement that is purely for consent.


Axel - we are discussing the now, for example in the case of age consent where consent needs to be renewed every 6 months


George - example could be an API that is sharing data that you’ve never shared with this user before - you are authenticated and authorized but haven’t given consent.  Would we use scopes?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240222/9b2132c4/attachment-0001.html>