[Openid-specs-ab] ServerMTI in Messages

John Bradley ve7jtb at ve7jtb.com
Wed Jan 30 22:06:25 UTC 2013


OP's that want to be interoperable;e should support none and RS256.  If they are not dynamically configured they need to communicate they to the client out of band along with everything else the client needs.

John
On 2013-01-30, at 6:59 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:

> OPs have to understand all the defined scope values but they don't have to return any claims for them.  They were always allowed to filter the set of claims returned, no matter what was requested.
> 
> To achieve strict interop, I would use an unsigned request object (or just scopes).  That, or observe what algorithms are supported in the  request_object_signing_alg_values_supported discovery response, and use one of those algorithms.
> 
> 					-- Mike
> 
> -----Original Message-----
> From: Torsten Lodderstedt [mailto:torsten at lodderstedt.net] 
> Sent: Wednesday, January 30, 2013 1:08 PM
> To: Mike Jones
> Cc: John Bradley; openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] ServerMTI in Messages
> 
> Hi Mike,
> 
> Am 30.01.2013 um 21:23 schrieb Mike Jones <Michael.Jones at microsoft.com>:
> 
>> http://openid.net/specs/openid-connect-messages-1_0.html#sigenc.alg says "Servers SHOULD support none and RS256."  So it's already not MTI.
> 
> If there is no MTI for signing, how is interoperability achieved for is tokens (esp. in conjunction with implicite grant type)?
> 
>> 
>> To Torsten's first question, the UserInfo endpoint is RECOMMENDED for static configurations as well.  The only reason it's not REQURIED is some static OPs may choose not to expose this information at all.  (They would only provide SSO but no claims.)
>> 
> 
> Which consequently means, the scope value "openid" is mandatory, whereas the other values for requesting claims are not?
> 
> regards,
> Torsten.
> 
>>               -- Mike
>> 
>> -----Original Message-----
>> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John Bradley
>> Sent: Wednesday, January 30, 2013 4:38 AM
>> To: Torsten Lodderstedt
>> Cc: openid-specs-ab at lists.openid.net
>> Subject: Re: [Openid-specs-ab] ServerMTI in Messages
>> 
>> The problem with the user info endpoint is that it can't be supported by self issued providers so always making it MTI won't work.
>> 
>> Just because a provider doesn't support discovery and registration, I wouldn't expect them  to not have a user info endpoint.
>> 
>> The default signing for request objects should be RS256.  I would prefer not to make RS256 MTI as it may be legitimate for a server to support only ECDH for security reasons.
>> 
>> I would be OK with saying the server needs to support one of RS256, RS512, ES512.  So if they don't want to support the default they have to support one of the more secure ones.
>> 
>> The problem is what happens when someone only wants to support ECDSA with SHA3?   That is the problem with MTI.
>> 
>> John B.
>> 
>> On 2013-01-30, at 8:25 AM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
>> 
>>> Hi all,
>>> 
>>> just re-read the MTI section of messages (8.1. specifically), which caused two questions:
>>> 1) Assuming the scope values "profile", "email", "address" and "phone" are required for all server implementations, how is a non-dynamic OpenID provider supposed to expose this data? I'm asking since the UserInfo endpoint is MTI for dynamic OpenID providers, only.
>>> 2) Which are the default signing algorithms for request objects? Discovery says "Servers SHOULD support none and RS256".
>>> 
>>> regards,
>>> Torsten.
>>> 
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab



More information about the Openid-specs-ab mailing list