[Openid-specs-ab] response_types_supported

John Bradley ve7jtb at ve7jtb.com
Thu Jan 26 11:48:41 UTC 2012

In OAuth core response_type is a single value that may contain spaces.

If 'response_types_supported': [u'code', u'token', u'id_token']

You can't assume the authorization server supports response_type=code%20token%20id_token

The example in Dioscovery is:
"response_types_supported": ["code", "code id_token", "token id_token"],

We don't say that it is required or what the default is in Discovery.

code is probably a reasonable default.   We will need to ass some text.

On 2012-01-26, at 5:20 AM, Roland Hedberg wrote:

> Hi!
> If a client gets back:
> 'response_types_supported': [u'code', u'token', u'id_token']
> as part of the response on a provider configuration request.
> Does this mean that any and all combinations of the three are supported ?
> Or does all combinations have to be explicitly listed, a'la
> 'response_types_supported': [u'code', u'token', u'id_token', u'code token', u'code id_token', u'id_token token']
> ??
> If 'response_types_supported' is omitted then I assume this is equivalent to:
> 'response_types_supported': [u'code']
> -- Roland
> _______________________________________________
> 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: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120126/a216c63e/attachment.p7s>

More information about the Openid-specs-ab mailing list