Implementation/standards issue

[Roland Hedberg]

Hi!

I stumbled onto this when I went through the examples in the specification looking for missing 

required claims. This because of Vlad’s issue 

https://bitbucket.org/openid/connect/issues/1151/federation-a1-examples-of-op-metadata-in

A bit of background. In https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata

It’s stated that for token_endpoint_auth_methods_supported, if the claims is omitted from the

metadata, the default is [“client_secret_basic”].

My interpretation of this is that if an OP in an entity statement publishes a metadata statement that does not 

contain a token_endpoint_auth_methods_supported claim. The metadata should be handled as if it contained

token_endpoint_auth_methods_supported = [“client_secret_basic”] when metadata policies are applied.

This makes the resulting metadata as it stands in A.1.8 wrong. Instead an error should be reported.

I’ll change the example to actually be correct. 

token_endpoint_auth_methods_supported is just one example there are more claims that have default values.

This is obviously one thing we have to look for when we do the interop testing.

— Roland

Were it left to me to decide whether we should have a government without newspapers, or newspapers without a government, I should not hesitate a moment to prefer the latter. -Thomas Jefferson, third US president, architect, and author (1743-1826) 

[Jouke Roorda]

Hey,

I would say that implicit values are a valid option only if they are
very clearly specified, and absolutely _never_ change. Otherwise
enforcing their presence would be better.

Also, because Vladimir should be on this list, and I dont have
bitbucket: the extra dot is not superfluous, its how x509 naming
constraints are specified.

> --
> You received this message because you are subscribed to the Google
> Groups "openid-federation-interop" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openid-federation-...@googlegroups.com
> <mailto:openid-federation-...@googlegroups.com>.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/openid-federation-interop/A2B8D348-B711-418C-9651-C3791BD0D290%40catalogix.se
> <https://groups.google.com/d/msgid/openid-federation-interop/A2B8D348-B711-418C-9651-C3791BD0D290%40catalogix.se?utm_medium=email&utm_source=footer>.

--
Jouke Roorda | Software Engineer @ Nikhef
Computer Technology / Physics Data Processing

F8B6 CDFD 1330 8AA1 9EDD 0EAF 69DC 76E2 B4F3 4F61

[Roland Hedberg]

On 24 Feb 2020, at 15:50, Jouke Roorda <jou...@nikhef.nl> wrote:

I would say that implicit values are a valid option only if they are
very clearly specified, and absolutely _never_ change. Otherwise
enforcing their presence would be better.

Now I don’t think we can (or should) change the way people have interpreted the standard.

Default values are clearly specified and they are valid as long as the standard is valid.

I think my interpretation is the one that is used and will continue to be used.

It just had implications for the application of metadata policies I didn’t see to begin with.

Which probably means we should write explicitly about this.

Now, there are other quirks and an example of that is for instance id_token_signing_alg_values_supported

for which there is no default value but where it is stated that one of the values in the list MUST be “RS256”.

To unsubscribe from this group and stop receiving emails from it, send an email to openid-federation-...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openid-federation-interop/dba17e15-e59c-bdf4-d33a-2c4171da0160%40nikhef.nl.

— Roland

It is curious that physical courage should be so common in the world, and moral courage so rare. -Mark Twain, author and humorist (30 Nov 1835-1910)

[Vladimir Dzhuvinov]

On 24/02/2020 18:39, Roland Hedberg wrote:

Also, because Vladimir should be on this list, and I dont have
bitbucket: the extra dot is not superfluous, its how x509 naming
constraints are specified.

Thanks, this is good to know! We totally missed that.

If anyone is interested about the constraints syntax:

https://tools.ietf.org/html/rfc5280#section-4.2.1.10

   When the constraint begins with a period, it MAY be
   expanded with one or more labels.  That is, the constraint
   ".example.com" is satisfied by both host.example.com and
   my.host.example.com.  However, the constraint ".example.com" is not
   satisfied by "example.com".  When the constraint does not begin with
   a period, it specifies a host.

Vladimir

-- 
Vladimir Dzhuvinov

[Roland Hedberg]

I basically copied that part from RFC580 into section 4.2.2 Naming Constraints of

the federation specification.

--
You received this message because you are subscribed to the Google Groups "openid-federation-interop" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openid-federation-...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/openid-federation-interop/d2ae8ba1-96f0-eced-bd9a-8755aca1c47d%40connect2id.com.

— Roland

Can anything be sadder than work left unfinished? Yes, work never begun. -Christina Rossetti, poet (5 Dec 1830-1894) 

[Vladimir Dzhuvinov]

Yep, I found it:

https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.7.3.2

To view this discussion on the web, visit https://groups.google.com/d/msgid/openid-federation-interop/0262A8A0-A8E2-4A09-9F3E-EDC79FCE77B3%40catalogix.se.

-- 
Vladimir Dzhuvinov