<div dir="ltr">Policy languages also came up in the DCP meeting. <div>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.</div><div>I plan to create a sanitized version that I can share.</div><div>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.</div><div><br></div><div><h2><span class="gmail-mw-headline" id="gmail-Full_Title_or_Meme">Full Title or Meme</span></h2><p>What should a request to the wallet look like to achieve the purpose of the <a href="https://tcwiki.azurewebsites.net/index.php?title=Verifier" title="Verifier">Verifier</a> and the privacy of the <a href="https://tcwiki.azurewebsites.net/index.php?title=Subject" title="Subject">Subject</a>.
</p><p>Also known as a Generic Wallet Query Language.
</p>
<h2><span class="gmail-mw-headline" id="gmail-Context">Context</span></h2><p>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 <a href="https://tcwiki.azurewebsites.net/index.php?title=Verifier" title="Verifier">Verifier</a> in any jurisdiction can make a request that all digital <a href="https://tcwiki.azurewebsites.net/index.php?title=Wallet" title="Wallet">Wallets</a>
could meaningfully handle to allow existing purposes. The use cases
listed below include cases were interoperability of wallets with
disparate requirements in diverse identity <a href="https://tcwiki.azurewebsites.net/index.php?title=Ecosystem" title="Ecosystem">Ecosystems</a> are important to the person that selects which wallet to use.
</p>
<h2><span class="gmail-mw-headline" id="gmail-Problems">Problems</span></h2><ol><li> Users will not select <a href="https://tcwiki.azurewebsites.net/index.php?title=Wallet" title="Wallet">Wallets</a>
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.</li>
<li> When the request from the <a href="https://tcwiki.azurewebsites.net/index.php?title=Verifier" title="Verifier">Verifier</a>
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.</li>
<li> Many states in the US are issuing <a href="https://tcwiki.azurewebsites.net/index.php?title=Mobile_Driver%27s_License" title="Mobile Driver's License">Mobile Driver's License</a> wallets that can only hold their own <a href="https://tcwiki.azurewebsites.net/index.php?title=State_Issued_Identifier" title="State Issued Identifier">State Issued Identifiers</a>. Thus using that <a href="https://tcwiki.azurewebsites.net/index.php?title=Wallet" title="Wallet">Wallet</a> for other purposes of the <a href="https://tcwiki.azurewebsites.net/index.php?title=Verifier" title="Verifier">Verifier</a> will force the user to select different wallets to gain access the the desired resource. A solution that many user will avoid.</li>
<li> 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.</li>
<li></li></ol>
<h2><span class="gmail-mw-headline" id="gmail-Use_Cases">Use Cases</span></h2><ol><li> A wallet that holds a California <a href="https://tcwiki.azurewebsites.net/index.php?title=Mobile_Driver%27s_License" title="Mobile Driver's License">Mobile Driver's License</a> can be used to enter a bar in a different country with different legal requirements.</li>
<li> A shopper at a grocery store wants to give the store their <a href="https://tcwiki.azurewebsites.net/index.php?title=Loyalty_ID" title="Loyalty ID">Loyalty ID</a>
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.</li>
<li> A sovereign state needs <a href="https://tcwiki.azurewebsites.net/index.php?title=State_Mandated_Identification" title="State Mandated Identification">State Mandated Identification</a> in order to have a consistent <a href="https://tcwiki.azurewebsites.net/index.php?title=Identifier" title="Identifier">Identifier</a> for any of the several hundred licenses and other uses of that State.</li></ol>
<h2><span class="gmail-mw-headline" id="gmail-Solutions">Solutions</span></h2><p>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.
</p>
<ol><li> 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.</li>
<li> 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.</li></ol></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap"> </span>..tom</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 22, 2024 at 8:05 AM Pamela Dingle via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg4373957671638895580">
<div dir="ltr">
<p style="margin-top:0px;margin-bottom:0px"><span style="font-family:"Helvetica Neue";font-size:20px;color:rgb(0,0,0)"><b>OpenID Connect Weekly Meeting Notes</b></span></p>
<p style="line-height:normal;margin:0px;min-height:15px">
<span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Date: 22 Feb 2024</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Attending: G. Fletcher, M. Jones, B. Campbell, P. Dingle. A Nennker, B. Helm</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Scribe: P. Dingle</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><b>Official business:</b></span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Issue filed by Axel:
<a href="https://bitbucket.org/openid/connect/issues/2118/federation-introduce-sector_identifier-to" id="m_-7213119616686916398OWA6d5e5a92-a848-7e61-1102-dbedd86ce5be" style="margin-top:0px;margin-bottom:0px" target="_blank">
https://bitbucket.org/openid/connect/issues/2118/federation-introduce-sector_identifier-to</a></span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Mike - Federation has no subject identifiers, so how would a sector identifier be represented in the opened federation spec?</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">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.</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Pam - could this be about specifying in metadata how the subject identifier is constructed</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Alex - maybe, maybe you could specify PPID_enum in Connect and then fill that with the needed method for the sector identifier?</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Mike - we have defined that for dynamic client registration, could that value be re-used?</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Alex - maybe, will go look.</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Action: Mike and George to add context to the issue.</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><b>Beginning of meeting was freeform conversation </b></span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Question from George - how to structure representation of specific policy satisfaction “step-up” in OpenID Connect</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<ul style="list-style-type:disc">
<li style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0);line-height:normal;margin:0px">
<span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Insufficiency needs to be represented - how does it say what is required back to the AS?</span></li><li style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0);line-height:normal;margin:0px">
<span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">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”</span></li></ul>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Scope could be overloaded, ie “urn:somepolicychain” but it isn’t exactly what we need</span></p>
<ul style="list-style-type:disc">
<li style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0);line-height:normal;margin:0px">
<span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Could we add a policy element to the WWW response?</span></li></ul>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Question from Mike: how does this related to the RAR spec?</span></p>
<ul style="list-style-type:disc">
<li style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0);line-height:normal;margin:0px">
<span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">9470 is unlikely to contain PII where as RAR</span></li></ul>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Pam - this also relates to SSF/CAEP, we have a requirement to potentially inform RS’s of simple policies to be enforced</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">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. </span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">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 </span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">George - most amrs result in a possession factor - we’ve lost the “something you know”. - if all your password </span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">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 </span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">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</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">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</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">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</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Brian- that was the original idea behind authorization context, we created identifiers that represent policies, </span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">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.</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">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.</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">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” . </span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Pam - maybe there is a new thing beside access denied — these days there is accept, deny, redirect to honeypot, redirect and detect/signal
risk</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">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”</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">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.</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Pam - do folks think this can be defined? Should we try (seemed to be consensus that we should try)</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">George- you could have a step-up requirement that is purely for consent.</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">Axel - we are discussing the now, for example in the case of age consent where consent needs to be renewed every 6 months</span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span></p>
<p style="line-height:normal;margin:0px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)">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? </span></p>
<p style="line-height:normal;margin:0px;min-height:15px"><span style="font-family:"Helvetica Neue";font-size:13px;color:rgb(0,0,0)"><br>
</span><span style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><br>
</span></p>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div></blockquote></div>