I just looked all the uses of REQUIRED and MUST in the OpenID Connect Core
spec. They do things like say which claims are REQUIRED in the ID Token
("iss", "sub", etc.), which OAuth parameters and features are REQUIRED, place
restrictions on certain values (such as "iss" MUST use the "https" scheme,
"sub" must not be longer than 255 characters, the redirect_uri MUST exactly
match a registered value, etc.), say that fields that are not understood MUST
be ignored, and say when ID Tokens MUST be signed, and say that user
interaction MUST NOT occur with prompt=none, and specify validation rules for
some data structures (checking signatures, redirect_uris, etc.).
The key point is that none of the uses of REQUIRED or MUST require
implementation of additional features, either by OPs or RPs. They just place
restrictions on *how* they are to be implemented. So, in fact, the lists in
15.1 and 15.2 *are* comprehensive sets of required features for the two classes
of identity providers.
I should have added in my earlier note that there's also a section on MTI
features for RPs:
15.4.<http://openid.net/specs/openid-connect-core-1_0.html#RPMTI>
Mandatory to Implement Features for Relying Parties
Essentially, it says that RPs only need to implement the features that they
actually plan to use.
Developers have shown in practice to have no problem understanding the OpenID
Connect specs or building interoperable implementations. 20 implementations
(see http://osis.idcommons.net/wiki/Category:OC5_Solution) are participating in
the current (5th) round of interop testing and a number of others also are
privately. The specs are clear to developers in part because we kept
iterating, taking feedback, refining them, and doing new rounds of interop
testing until they were clear and easy to build. There's four years of
implementation and deployment experience incorporated into the final
specifications.
No, everyone won't build every optional feature. That's a good thing - and by
design. The specs are designed to let you build only the parts that you need
for your use cases, while still being interoperable for the features
implemented.
Yes, the a4c spec adds a few things that OpenID Connect didn't - primarily the
ability to authenticate over the back channel without issuing an ID Token by
adding a new response_type, plus definitions of some claim values for the "amr"
claim. There's nothing wrong with these additions.
However, arguments that "OpenID Connect is too complicated" fall short in face
of the actual implementation and deployment experience and I don't think are
helpful to the current discussions. We should be positively discussing what
features OAuth specs should have, rather than trying to criticize other
valuable work that's already widely deployed.
Best wishes,
-- Mike
From: Prateek Mishra [mailto:[email protected]]
Sent: Friday, June 13, 2014 9:55 AM
To: Mike Jones; Bill Burke; Phil Hunt
Cc: [email protected]
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
Mike - when i see language like
[quote]
This list augments the set of features that are already listed elsewhere as
being "REQUIRED" or are described with a "MUST", and so is not, by itself, a
comprehensive set of implementation requirements for OPs.
[\quote]
in Section 15.1, I have to say this isn't a clear definition of what is MTI.
I guess someone could through comprehensive research determine exactly what
might be meant by this section, but that doesn't meet the criteria of "very
clear definition of MTI".
- prateek
- prateek
Actually, there is a very clear definition of what the minimal Mandatory To
Implement (MTI) in OpenID Connect is - it's right in the spec. See the (quite
short) sections:
15.1.<http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI>
Mandatory to Implement Features for All OpenID Providers
15.2.<http://openid.net/specs/openid-connect-core-1_0.html#DynamicMTI>
Mandatory to Implement Features for Dynamic OpenID Providers
-- Mike
-----Original Message-----
From: OAuth [mailto:[email protected]] On Behalf Of Prateek Mishra
Sent: Friday, June 13, 2014 9:24 AM
To: Bill Burke; Phil Hunt
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
Excellent, now you have put your finger on the precise issue with OIDC - lots
of optional extensions and shiny trinkets and lack of a clear definition of a
core subset for servers.
I realize its exciting for consultants, software and toolkit vendors to have
that sort of optionality, but in practice, its NOT A GOOD THING in a protocol.
[quote]
>
>> It is a bit like saying an 18 wheeler is suitable for driving the
>> kids to school. :-)
>
> I don't think this is true. Most oidc oauth extensions are optional
> with the sole requirement that providers don't barf if you send them.
>
[\quote]
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
