<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>You keep ommiting the RP may want the OP to only accept request objects and it will set the appropriate signing alg to force anything but “none”. It’s not just the other way around (OP policy). </div><div><br></div>So I’ll create an issue in the tracker for discussing whether you will amend the <span style="background-color: rgba(255, 255, 255, 0);">request_object_signing_alg language (if it was intended to be as such in the first place) or adopt (and discuss how) request_object_required and we can discuss it in the next call. </span><div><br></div><div>Filip<br><div><br><div>Odesláno z iPhonu</div><div><br>12. 8. 2018 v 19:08, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>>:<br><br></div><blockquote type="cite"><div>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
samp
{mso-style-priority:99;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#002060;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#002060">Wow – I’d forgotten the we even specified how to do symmetric encryption. Are you aware of anyone actually doing this?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">I do think I agree with Ralph that it’s up to the RP whether to do encryption. I do agree that the OP wants to be able to reject requests that aren’t signed if that’s what its security profile requires.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>>
<b>On Behalf Of </b>Filip Skokan via Openid-specs-ab<br>
<b>Sent:</b> Sunday, August 12, 2018 1:51 AM<br>
<b>To:</b> <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a> Ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>>; <a href="mailto:openid-specs-fapi@lists.openid.net">openid-specs-fapi@lists.openid.net</a><br>
<b>Cc:</b> Filip Skokan <<a href="mailto:panva.ip@gmail.com">panva.ip@gmail.com</a>><br>
<b>Subject:</b> Re: [Openid-specs-ab] [Openid-specs-fapi] Proposal for "Required Request Object Use" Dynamic Registration extension<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I also gave a thought to just a new property saying encryption is required. But there’s a big difference in the symmetrical/non-symmetrical algs here. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Anyone can encrypt for the OP using its public assymetrical keys published in jwks_uri. But only the parties knowing a client secret can encrypt using the symmetrical ones. And since the current encryption alg
language clearly says the RP may in the end use any supported alg, I went the route of proposing for enforcing the negotiated ones like so. <o:p></o:p></p>
<div id="AppleMailSignature">
<p class="MsoNormal">Odesláno z iPhonu<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
12. 8. 2018 v 9:32, Filip Skokan <<a href="mailto:panva.ip@gmail.com">panva.ip@gmail.com</a>>:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Hello Mike, Ralph,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><span style="color:#002060">Mike> It’s not clear to me that this is needed. Rather, we could clarify that if “</span><i>request_object_signing_alg</i><span style="color:#002060">” is present, it’s also to be interpreted as a request by
the server to only send signed requests. That would be simpler than adding an additional parameter.</span><o:p></o:p></p>
</blockquote>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Was this the initial intention of <span style="font-size: 11pt;">request_object_signing_al</span><span style="font-size: 11pt;">g or just algorithm negotiation again? Clarify how? IIRC you can't change the normative requirement, and currently there's none to be found in the language that would enforce this.</span></p></div></div></div></blockquote></div></div></div></blockquote><blockquote type="cite"><div class="WordSection1"><div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><div><div><p class="MsoNormal"><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><span style="color:#002060">Mike> And again, I believe that the OP can already require the use of encryption by publishing “request_object_encryption_alg_values_supported” and “request_object_encryption_enc_values_supported” metadata values.</span><o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Neither one of these discovery metadata nor the registered client metadata makes making use of an encrypted Request Object a MUST. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><span style="color:black">Ralph> None of the OB implementors have called out confusion with these values yet.</span><o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm not confused with the existing values either, it's just that they don't enforce the secure mode of operation that I think we should have the possibility of requiring. It's rather easy for FAPI implementers since they have a MUST in
the spec so then they take these parameters as such. But I'd like to see that possible for a regular OP/PR, not just FAPI ones, without going against the normative language.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><span style="color:#002060">Mike> Let’s talk about this on one of the upcoming working group calls.</span><o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'll do my best to be there.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Bottom line, if this comes down to be request_object_signing_alg missing a normative requirement to reject requests without it I believe errata would be a wrong choice here as there can't be any confusions with the current language that
this is only applied IF request object is provided.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">Best,<br>
<b>Filip</b><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Sun, Aug 12, 2018 at 9:12 AM Ralph Bragg via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net">openid-specs-fapi@lists.openid.net</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Personally I agree with Mike. None of the OB implementors have called out confusion with these values yet. Specifying whether or not I need to encrypt or sign a request should be up to the RP not the OP, if the content is sensitive, for
example it includes claim values to be verified it should be encrypted, if it does not then signing works for me.
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Additionally, for FAPI, given the focus on requirement for non repudiation and UA /MITB attacks, I’d prefer to see the language tightened up so that all requests are sent by the signed request so mikes langauage change to use the presence
of the alg a requirement for use as well works for me. Ultimately it doesn’t make a huge difference except to improve consistency of configuration which is a good thing so if the majority wants to explicitly add these IANA types then that’s fine as well. existing
implementations can be extended easily enough. <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="4" width="98%" align="center">
</div>
<div id="gmail-m_-1445566292094227388divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> 31002760740n behalf of
<br>
<b>Sent:</b> Sunday, August 12, 2018 00:15<br>
<b>To:</b> Artifact Binding/Connect Working Group; <a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">
openid-specs-fapi@lists.openid.net</a><br>
<b>Cc:</b> Mike Jones<br>
<b>Subject:</b> Re: [Openid-specs-fapi] [Openid-specs-ab] Proposal for "Required Request Object Use" Dynamic Registration extension
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060">Thanks for sending this, Filip. I’ve added some initial thoughts inline below, prefixed by “Mike>”.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>>
<b>On Behalf Of </b>Filip Skokan via Openid-specs-ab<br>
<b>Sent:</b> Saturday, August 11, 2018 6:50 AM<br>
<b>To:</b> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a> Ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>;
<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a><br>
<b>Cc:</b> Filip Skokan <<a href="mailto:panva.ip@gmail.com" target="_blank">panva.ip@gmail.com</a>><br>
<b>Subject:</b> [Openid-specs-ab] Proposal for "Required Request Object Use" Dynamic Registration extension<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hello everyone,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I'd like to propose an additional (or Dynamic Registration 1.1) entry into the openid spec family / IANA "OAuth Dynamic Client Registration Metadata" that allows for OPs and RPs
to get assurances about the used JWT Request Objects in Authorization Requests.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>1) signaling that a request object must always be present in Client's authorization requests</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">why are current parameters not enough?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The closest comes
<i>request_object_signing_alg</i>, but its worded as <i>"All Request Objects from this Client MUST be rejected, if not signed with this algorithm. ... This algorithm MUST be used both when the Request Object is passed by value or ...".</i><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Meaning if there's no request object at all, request is still valid. This allows a malicious user to form his own authorization request with the properties the RP wishes to protect
(e.g. claims containing PII, required amr or other sensitive information necessary for the authorization request, max_age, acr_values) in the query instead.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Proposed client registration metadata:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-top:6.0pt;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Courier New";color:black">request_object_required</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Courier New";color:black">OPTIONAL. Boolean value specifying whether the OP should accept an Authorization Request without a Request Object for processing. If <samp>true</samp>, the OP MUST reject Authorization Requests
without Request Object passed by value (using the <samp>request</samp> parameter) or by reference (using the <samp>request_uri</samp> parameter) with the error <samp>invalid_request</samp>. If omitted, the default value is <samp>false</samp>.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060">Mike> It’s not clear to me that this is needed. Rather, we could clarify that if “</span><i>request_object_signing_alg</i><span style="color:#002060">”
is present, it’s also to be interpreted as a request by the server to only send signed requests. That would be simpler than adding an additional parameter.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>2) enforcing request object encryption</b> - this one I didn't quite figure out a vector for yet<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">why are current parameters not enough?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><i>request_object_encryption_alg</i> states <i>"JWE algorithm the RP is declaring that it may use for encrypting Request Objects sent to the OP. ... The RP MAY still use other supported
encryption algorithms or send unencrypted Request Objects, even when this parameter is present."</i> so the request object may still be sent without encryption.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">This smells of a very easy downgrade-attack (when symmetrical encryption is used) vulnerability with no normative protection against it. I mention I can't figure out a vector for
this but just plain possibility of abandoning high-quality mode of operation directly in the specification is what I wish to get rid of.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060">Mike> This parameter (and the “enc” variant) are about telling the OP about the encryption capabilities of the RP. This is one half of the algorithm
negotiation. I believe that it’s the OP’s decision whether to require encryption of request objects – not the RP’s.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Proposed client registration metadata:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-top:6.0pt;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Courier New";color:black">request_object_encryption_alg_required</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Courier New";color:black">OPTIONAL. Boolean value specifying whether the <samp>alg</samp> algorithm specified by <samp>request_object_encryption_alg</samp> MUST be used for encrypting Request Objects sent to the OP.
When <samp>request_object_encryption_alg_required</samp> is <samp>true</samp> all Authorization Requests with Request Objects from this Client MUST be rejected with the error <samp>invalid_request_object</samp>, if not encrypted with this algorithm or not
encrypted at all. When <samp>request_object_encryption_alg_required</samp> is <samp>true</samp>, <samp>request_object_encryption_alg </samp>MUST also be provided and this algorithm MUST be used both when the Request Object is passed by value (using the <samp>request</samp> parameter)
and when it is passed by reference (using the <samp>request_uri</samp> parameter). If omitted, the default value is <samp>false</samp>.</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-top:6.0pt;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Courier New";color:black">request_object_encryption_enc_required</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Courier New";color:black">OPTIONAL. Boolean value specifying whether the <samp>enc</samp> algorithm specified by <samp>request_object_encryption_enc</samp> MUST be used for encrypting Request Objects sent to the OP.
When <samp>request_object_encryption_enc_required</samp> is <samp>true</samp> all Authorization Requests with Request Objects from this Client MUST be rejected with the error <samp>invalid_request_object</samp>, if not encrypted with this algorithm or not
encrypted at all. When <samp>request_object_encryption_enc_required</samp> is <samp>true</samp>, <samp>request_object_encryption_enc </samp>MUST also be provided and this algorithm MUST be used both when the Request Object is passed by value (using the <samp>request</samp> parameter)
and when it is passed by reference (using the <samp>request_uri</samp> parameter). If omitted, the default value is <samp>false</samp>.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Additionally, having these metadata defined allows an OP to send these in Dynamic Registration Response as a policy of sorts.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060">Mike> First, these two parameters really should just be one – if adopted, because what you’re really saying is that encryption is required. (It just
happens that you need two algorithms values to say *<b>how</b>* the encryption is done.) And again, I believe that the OP can already require the use of encryption by publishing “request_object_encryption_alg_values_supported” and “request_object_encryption_enc_values_supported”
metadata values. I believe that adding this RP metadata value would likely be redundant.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I'd like to get your feedback on this proposal and I am also able to form a specification around this if it's welcome.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I'm sending this to both AB/Connect and FAPI working groups, considering that FAPI requires the use of signed and/or encrypted request objects Mike Jones figured it'd be something
you might be interested in. While some form of normative requirement is already present in the FAPI specifications introducing these metadata MAY allow a single OP to operate both in secure and insecure modes at the same time depending on the provisioned or
dynamically registered client.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Since my IPR Agreement for FAPI WG is not yet processed someone please forward there.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Kind Regards,<br>
<b>Filip</b><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060">Mike> Let’s talk about this on one of the upcoming working group calls.</span><br clear="all">
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> Thanks,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> -- Mike</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote></div></div></body></html>