+1
This is clearly an extension to OIDC and should be handled in the OIDF
so that it doesn't needlessly compete with OIDC. I see no reason for the
IETF to take on this work.
-- Justin
On 6/13/2014 5:34 PM, Anil Saldhana wrote:
Brian - I agree. We should neither overload nor extend the WG charter
to include any aspect of SSO or authentication.
I am hoping Prateek/Phil's feedback on OIDC can be addressed by OIDC.
From John's email, it seemed like a path forward is a Deployment
Profile at OIDC. Hopefully everybody will be happy with that.
On 06/13/2014 04:23 PM, Brian Campbell wrote:
I agree that, at this point, debating the details of a4c is
premature. SSO/authentication are not part of the WG charter and, as
I've said before, I'd object to changing the charter to include it.
Other than a small but vocal minority, I think it's fair to say that
that's also been the prevailing sentiment of this group.
On Fri, Jun 13, 2014 at 1:43 PM, John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> wrote:
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 <mailto: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 <mailto: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
