[Openid-specs-ab] Spec Call Notes 12-Mar-20

[Nicholas Roy]

On 12 Mar 2020, at 10:21, Torsten Lodderstedt via Openid-specs-ab wrote:

> Hi,
>
> I would like to add my my 2¢.
>
>>
>>
>> MTLS and Self-Signed Certificates
>>               Higher-education uses a lot of self-signed certificates in SAML federations
>>               They are also used to using MTLS
>>                            Torsten wants to use MTLS
>>               Mike asked why not just use private_key_jwt?
>
> Because mTLS provides sender-constraining. Beside this, I don’t understand why a OIDF specification should limit the applicable client authentication methods.
>
>>                            Joseph said that in FAPI, people have a lot more deployment problems with MTLS than private_key_jwt
>>               Python doesn't successfully process self-signed client certificates
>>                            Brian thinks that you can do this in Java by overriding a certificate verification method
>
> The standard solution is to terminate TLS at a web server and just send the certificate to the app server as a header.
>
>>               The Federation spec uses private_key_jwt at the authorization endpoint
>>                            This requires that the audience be the authorization endpoint
>>               Brian stated that MTLS isn't defined or possible at the authorization endpoint
>>                            Only at the token endpoint
>>               Roland will take this offline with Brian and the authors
>
> The issues I raised was:
> - the federation spec requires client authentication at the authorization endpoint in order to use the automatic registration.
> - This functionality relies on private_key_jwt or put it the other way around: A client cannot use it in conjunction with other client authentication methods. I don’t see a compelling reason for this restriction.
> - I kind of understand why there is a desire to authenticate the client in the authorization request. But client authentication in OAuth and OpenId traditionally happens at the token endpoint. Automatic registration could do the same.
> - If people want early authentication and refusal, just adopt PAR, which provides this capability without restricting the client authentication methods.
>
> Side note: the current spec does not prevent replay, so an attacker passing as a user could obtain a valid assertion and replay it at other endpoints to pose as the legit client.
>
>>               Joseph said that FAPI has a pushed request object
>>                            Brian said that OAuth PAR is intended to be better specified and interoperable
>>
>> Federation Specification and Interops
>>               The Federation draft is at second Implementer's Draft status
>>               It's pretty stable, other than possibly changes responding to the MTLS feedback
>
> I like the federation spec as it stands today, but we (yes.com running/managing a IDP federation of financial institutions) cannot adopt it due to the limitations outlined above. I’m concerned this spec stays in a certain community and won’t see broad adoption beyond that.

I’m in favor of pretty much anything that would make that profile appealing beyond just R&E.

Nick

>
> best regards,
> Torsten.
>
>>               An interop is planned at TNC in Brighton in June
>>                            It's looking like this may have to be virtual
>>                            Roland knows of three implementations: from Germany, Finland, and Sweden
>>                            Or they could relocate the interop to Stockholm, for instance
>>                            Mike said that implementers could be putting up their public test endpoints now
>>               Roland has some clarifications to check into the spec
>>
>> Certification and Logout
>>               OP and RP logout certification are in pilot mode
>>               We want people testing before we take the Logout specs to Final status
>>               George will test Verizon Media's Front-Channel Logout implementation
>>
>> Open Issues
>>               https://bitbucket.org/openid/connect/issues?status=new&status=open
>>               #1150 Federation: 9.1.1 Endpoint should be "authorization"
>>                            Roland agrees with that correction
>>               #1151 Federation: A.1: Examples of OP metadata in entity statement and merged stament missing required parameters
>>                            Roland has addressed this in his local copy
>>               #1154 Federation: Explicit defintion of entity identifier
>>                            Roland has addressed this in his local copy
>>               #1155 Federation: 4.1.3: Typo in superset_of JSON example
>>                            Assigned to Roland
>>               #1156 Federation: 4.1.1. subset_of edge cases
>>                            Roland has addressed in his local copy
>>               #1157 Federation: 4.3: Combining Policies - Reword "combine" as "merge" where appropriate?
>>                            Assigned to Roland
>>               #1158 Federation 4 /7.2 - not clear handling when 'metadata' duplicated in the trust chain
>>                            Roland will clarify when metadata can appear and when metadata policy can appear
>>               #1159 TLS requirements/recommendations for OP/RP
>>                            Mike will update the TLS recommendations text
>>
>> Next Call
>>               The next working group call is scheduled for Monday, March 16 at 4pm Pacific Time
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 512 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200313/12a409d1/attachment.asc>