[Openid-specs-igov] igov spec updated

[Phil Hunt]

Given that this is handled in OIDC discovery, I see this as an unjustified limitation.  

If the intent is NOT to share claims, then it seems contradictory to force the UserInfo endpoint to be available.

If its available, should the UserInfo endpoint act like there are no claims are available?  Should it return an unauthorized error?  

Rather than be “simple” the proposal seems under-defined.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>





> On Aug 22, 2016, at 12:55 PM, John Bradley via Openid-specs-igov <openid-specs-igov at lists.openid.net> wrote:
> 
> +1
>> On Aug 22, 2016, at 4:46 PM, Justin Richer via Openid-specs-igov <openid-specs-igov at lists.openid.net> wrote:
>> 
>> +1 to this. The idea is that you want clients to know what to expect from a system. Being able to count on a user info endpoint to get *something* allows a simplification of code paths.
>> 
>> — Justin
>> 
>>> On Aug 22, 2016, at 3:36 PM, Mike Varley via Openid-specs-igov <openid-specs-igov at lists.openid.net> wrote:
>>> 
>>> Hi Phil - on a call back on July 26th we discussed the UserInfo endpoint requirement:
>>> basically we err'd on the side of - Make it a MUST, and privacy conscious ecosystems can just return a 'sub' field with the pairwise anonymous identifier from the id_token (and no other fields - so no new information is actually returned in the UserInfo call). 
>>> 
>>> Also, we couldn't (at the time) think of scenarios where it would be a SHALL NOT. But we didn't think long on it :)
>>> 
>>> If there are such scenarios, it's easy to change, we should just include the words to guide implementors on when they shall/should and shall not/should not.
>>> 
>>> MV
>>> 
>>> 
>>> 
>>> 
>>> On 2016-08-22, 2:42 PM, "Phil Hunt (IDM)" <phil.hunt at oracle.com> wrote:
>>> 
>>>> What is the reasoning for making UserInfo a MUST? I can see arguments for making it unavailable. For one many gov scenarios want to make sure tracking is not possible. So there may be scenarios that are SHALL NOT. 
>>>> 
>>>> Phil
>>>> 
>>>>> On Aug 22, 2016, at 11:09 AM, Mike Varley via Openid-specs-igov <openid-specs-igov at lists.openid.net> wrote:
>>>>> 
>>>>> Hello all - I have updated the igov-profile spec on bitbucket with the following:
>>>>> 
>>>>> - removed authMode parameter
>>>>> - UserInfo endpoint support is now a MUST
>>>>> - client_secret_jwt authentication mode added
>>>>> 
>>>>> And some "scopes" that should help governments in defining profiles for their users, while allowing for cross-jurisdictional introp. And ID. This section will need a lot of discussion I hope - I was deliberately brief.
>>>>> 
>>>>> Attached is an HTML version.
>>>>> 
>>>>> Talk to you tomorrow,
>>>>> 
>>>>> MV
>>>>> 
>>>>> <openid-igov-profile-08-22.html>
>>>>> _______________________________________________
>>>>> Openid-specs-igov mailing list
>>>>> Openid-specs-igov at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-igov
>>>> 
>>> _______________________________________________
>>> Openid-specs-igov mailing list
>>> Openid-specs-igov at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-igov
>> 
>> _______________________________________________
>> Openid-specs-igov mailing list
>> Openid-specs-igov at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-igov
> 
> _______________________________________________
> Openid-specs-igov mailing list
> Openid-specs-igov at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-igov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-igov/attachments/20160822/bdb770a0/attachment-0001.html>