[Openid-specs-ab] Question on Dynamic Registration

Filip Skokan panva.ip at gmail.com
Thu Jun 1 20:42:43 UTC 2017


Hello Sascha,

As Justin mentioned, the server must enforce this, be it by requiring the
grant_types with the specific values implicit, authorization_code, or both,
or by automatically adding these to the metadata depending on the received
response_types.

Since you're asking for reference, node oidc-provider requires the values
to be provided by the client in the request, other than the mentioned "when
omitted" defaults (e.g. authorization_code) there's no modifying or
enriching the registration metadata. Having written both client and server
i find it easier to understand that the registration metadata is incomplete
(error with a clear message), rather than attempting to read out why is my
registration coming back with more than the client requested requested.

- Filip

On Thu, Jun 1, 2017 at 9:24 PM, Preibisch, Sascha H via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Thank you, Justin!
>
> My issue is that our customers expect our product to adhere to the spec.
> Therefore I cannot build in enforcements that are not specified.
>
> I feel that the spec. gives big room for interpretation in the area.
>
> If you or someone else would have references of typical implementations
> that would help.
>
> Thanks,
> Sascha
>
> From: Justin Richer <jricher at mit.edu>
> Date: Wednesday, May 31, 2017 at 6:12 PM
> To: Sascha Preibisch <sascha.preibisch at ca.com>
> Cc: "openid-specs-ab at lists.openid.net Ab" <openid-specs-ab at lists.openid.
> net>
> Subject: Re: [Openid-specs-ab] Question on Dynamic Registration
>
> The server needs to make sure that they’re consistent at the end of a
> successful registration. This could take the form of forcing the client to
> register a consistent set (response_type=code,
> grant_type=authorization_code) and returning an error otherwise.
> Alternatively, the server could try to fill in the missing blanks for the
> client. Whatever the server decides is the result, it echoes back to the
> client, effectively dictating to the client the results of the
> registration.
>
> If the server doesn’t support the requested grant type or response type,
> it should probably fail the registration request. If it doesn’t, it will
> just fail the authorization request later on.
>
>  — Justin
>
>
> On May 31, 2017, at 1:59 PM, Preibisch, Sascha H via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
> Hi all!
>
> A team member and I just had a discussion about dynamic registration.
> Specifically about this section:
> http://openid.net/specs/openid-connect-registration-1_
> 0.html#ClientMetadata
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dregistration-2D1-5F0.html-23ClientMetadata&d=DwMFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=7gpZwgA6J-66ZzRVOZ35WfAcDwwU5gYYOjWTTglaYWc&s=CPWlAukwMe2HJIcCAWQz82lNuoJJq8D-N0tSy-ylSHc&e=>
>
> We are not sure how "response_types" and "grant_types" are expected to be
> handled. This is not clear to us:
>
>    - if a client registers for any other response_type than "code", is
>    the client required to also include a "grant_type"?
>    - Or is it that the server has to be configured to support the
>    matching grant_type and fail otherwise?
>    - Should the server return the matching grant_types although the spec.
>    says to return "authorization_code" in the case of being omitted?
>
> It would be great to get some clarification on that.
>
> Thanks,
> Sascha
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwQFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=7gpZwgA6J-66ZzRVOZ35WfAcDwwU5gYYOjWTTglaYWc&s=5Qki9nltVlv269MCWWgdyr3fZbd8_P8qJ-luz7bkkbE&e=>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170601/beb4c288/attachment-0001.html>


More information about the Openid-specs-ab mailing list