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

Tom Jones thomasclinganjones at gmail.com
Thu Feb 22 18:00:14 UTC 2024 

Policy languages also came up in the DCP meeting.
While I have (worked on a team that) recently created a policy language for
user agents, I just realized that it is covered by an NDA and I cannot
share the doc i have right now.
I plan to create a sanitized version that I can share.
We also discussed a wallet query language.  I list here a doc that I
created for PEMC in Kantara that might help with the idea of a
genaric query language.

Full Title or Meme

What should a request to the wallet look like to achieve the purpose of the
Verifier <https://tcwiki.azurewebsites.net/index.php?title=Verifier> and
the privacy of the Subject
<https://tcwiki.azurewebsites.net/index.php?title=Subject>.

Also known as a Generic Wallet Query Language.
Context

Today it is possible to use a driver's license issued in California to
enter a bar in Thailand. The question arises about how a request from a
Verifier <https://tcwiki.azurewebsites.net/index.php?title=Verifier> in any
jurisdiction can make a request that all digital Wallets
<https://tcwiki.azurewebsites.net/index.php?title=Wallet> could
meaningfully handle to allow existing purposes. The use cases listed below
include cases were interoperability of wallets with disparate requirements
in diverse identity Ecosystems
<https://tcwiki.azurewebsites.net/index.php?title=Ecosystem> are important
to the person that selects which wallet to use.
Problems

   1. Users will not select Wallets
   <https://tcwiki.azurewebsites.net/index.php?title=Wallet> that cannot
   get them access to resources that they depend upon. This page focuses on
   the way to create a request from a verifier such that it can be handled by
   the wallets that the user is likely to have in their possession.
   2. When the request from the Verifier
   <https://tcwiki.azurewebsites.net/index.php?title=Verifier> includes
   multiple purposes it is not likely that the user can be expected to switch
   from one wallet to another. Nor is it clear that the user ID will be the
   same in two different wallets.
   3. Many states in the US are issuing Mobile Driver's License
   <https://tcwiki.azurewebsites.net/index.php?title=Mobile_Driver%27s_License>
   wallets that can only hold their own State Issued Identifiers
   <https://tcwiki.azurewebsites.net/index.php?title=State_Issued_Identifier>.
   Thus using that Wallet
   <https://tcwiki.azurewebsites.net/index.php?title=Wallet> for other
   purposes of the Verifier
   <https://tcwiki.azurewebsites.net/index.php?title=Verifier> will force
   the user to select different wallets to gain access the the desired
   resource. A solution that many user will avoid.
   4. Technologies, including cryptographic methods, are changing rapidly.
   If these changes are not accommodated by users with existing mobile
   devices, the user will not be able to use them until they upgrade their
   device.
   5.

Use Cases

   1. A wallet that holds a California Mobile Driver's License
   <https://tcwiki.azurewebsites.net/index.php?title=Mobile_Driver%27s_License>
   can be used to enter a bar in a different country with different legal
   requirements.
   2. A shopper at a grocery store wants to give the store their Loyalty ID
   <https://tcwiki.azurewebsites.net/index.php?title=Loyalty_ID> in order
   to take advantage of selective discounts available to loyal customers as
   they pay for their goods with a payment card also in their wallet.
   3. A sovereign state needs State Mandated Identification
   <https://tcwiki.azurewebsites.net/index.php?title=State_Mandated_Identification>
   in order to have a consistent Identifier
   <https://tcwiki.azurewebsites.net/index.php?title=Identifier> for any of
   the several hundred licenses and other uses of that State.

Solutions

This page describes two ways to handle requests from wallets that need to
serve multiple purposes in a single request to the wallet. While it is
possible that wallet could handle both types of request, interoperability
would be improved if only one of these methods were selected.

   1. Allow the request to contain both optional and required claims and
   list multiple purpose as advisory and not directly connected to the list of
   claims required.
   2. Allow the request to contain multiple purposes and let the holder
   make a choice on which purpose to consent. In many cases the purpose should
   be sufficient to determine the claims provided by the wallet. This has also
   been called the collection of transaction sets, where each transaction was
   related to one purpose. It is also possible for each purpose to list the
   specific data elements (claims) that are needed, but the long term goal
   would be for the purpose to be sufficient for that purpose. Each purpose
   could be required or option, but any data element listed in the purpose
   would be required.


..tom


On Thu, Feb 22, 2024 at 8:05 AM Pamela Dingle via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> *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?
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240222/c38c61c0/attachment-0001.html>

More information about the Openid-specs-ab mailing list