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

[Torsten Lodderstedt]

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. 

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3946 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200312/b9ac3957/attachment.p7s>