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> 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>
> 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
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
