Hi Anil,
There are a number of profile efforts being looked at in the OIDF. The Mobile
Network operators lead by the GSMA are starting profile work on a standard
profile that will be supported by mobile operators globally, that includes
looking at how a Client/RP/SP can register there client once for use across
multiple IdP AS, as well as standardized LoA and user-info schema extensions.
Torsten Lodderstedt is the chair of that effort and can chime in.
I suspect that a Basic IdP for SSO profile is significantly less ambitious than
that and could be done in the current Connect WG.
If there is interest from the members to start it. The main time blocking
factor might be getting a new grant_type spec approved in the the OAuth WG if
we wanted to support that.
The IdP profile is simple they can publish a discovery document saying they
only support that that limited feature set, that way they would also be
compatible with existing connect clients.
{
"scopes_supported": ["openid"],
"response_types_supported":["code"],
"response_modes_supported":["query"],
"grant_types_supported":["authorization_code", "code_id_token_only"],
"acr_values_supported":["2","3"]
}
They don't need to publish one if they don't intend to be discoverable to
clients but knowing what the path forward to supporting generic client is
helpful I think.
Everything exists now other than the new grant_type exists now.
The work would mostly be putting together the examples based on supporting a
minimal flow.
Now I should point out that there are people who believe that the default flow
should be implicit with the "id_token" response_type and intend to support that.
Phil's draft concentrates on only one use case. Having a IdP deployment
profile for it is not a problem, but it will not be for every IdP. That is
one of the reasons why discovery and registration are important features of
Connect.
John B.
On Jun 13, 2014, at 1:26 PM, Anil Saldhana <anil.saldh...@redhat.com> wrote:
> On 06/12/2014 04:18 PM, John Bradley wrote:
>> All but a handful of OAuth WG participants participated in developing OpenID
>> Connect.
>>
>> Yes some companies chose not to participate for whatever reasons and have
>> not committed to the mutual non assert IPR agreement, and that is
>> unfortunate, but not a reason to start again from scratch.
>>
>> Changing the OIDF IPR policy of totally open specifications based on non
>> asserts is also not a option.
>>
>> I have made comments on the current draft of a4c.
>>
>> I think a profile of Connect introducing a grant_type returning only an
>> id_token would be simpler than trying to do this as a separate spec.
>> I do note that you can do effectively the same thing now by using a code
>> response_type and a scope of openID. This doesn't result in any extra user
>> consent other than consenting to login to the RP the first time (though that
>> consent can be given in advance out of band in a enterprise scenario.
>>
>> When developing Connect we debated having a token endpoint response with
>> only a id_token but decided that it was not in the spirit of being a OAuth 2
>> profile. So we decided to return a access token even if the user info
>> endpoint contains no claims other then sub. People almost always want more
>> claims as they roll out a real deployment. It is easy to add them if you
>> have designed to be able to talk to a RS.
>> OAuth without a RS is a touch not OAuth.
>>
>> a4c also completely ignores modern development environments like node.js
>> where the client is in the user agent, that OAuth 2 and Connect support.
>>
>> By the time the OAuth WG is done with a4c it will likely be a similar size
>> as Connect if it addresses the same use cases.
>>
>> I still don't see the problem with having a deployment profile of Connect
>> that can meet 100% of the current stated use case for a4c.
> John - I am not fully familiar with the processes of OIDC. How much of an
> effort is it to get the deployment profile of OIDC connect rolling?
>
>>
>> I expect that the people here involved in Connect will form there own
>> opinions on comments regarding the number of participants and the quantity
>> of the work and review.
>>
>> Regards
>> John B.
>>
>>
>>
>>
>> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt <hzandb...@pingidentity.com>
>> wrote:
>>
>>> +1, after implementing OIDC I will support the claim that any SSO protocol
>>> with a minimal set of required features smaller than OIDC is insecure and
>>> any protocol with similar features but with different parameter names is
>>> just creating confusion and will increase chances of non-interoperable and
>>> insecure implementations
>>>
>>> Hans.
>>>
>>> On 6/12/14, 9:50 PM, Bill Burke wrote:
>>>>
>>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>>>>> The OpenID Connect 2.0 COre specification alone is 86 pages. It has
>>>>> received review from maybe a dozen engineers within the OpenID community.
>>>>>
>>>> The OpenID Connect spec is 86 pages because it pretty much rehashes the
>>>> OAuth2 spec walking through each flow and how Open ID Connect expands on
>>>> that flow. A4c looks like a subset of this work minus some additional
>>>> claims and, IMO, is incomplete compared to OIDC.
>>>>
>>>> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers. We
>>>> originally were creating our own oauth2 extension using JWT, but found
>>>> that any feature we wanted to define already existed in OpenID Connect.
>>>> These guys have done great work. Aren't many of you here authors of
>>>> this spec and/or the same companies?!? I think your energies are better
>>>> focused on lobbying OIDC to join the IETF and this WG.
>>>>
>>>>
>>>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
