Let's come back to the problem statement. It sounds like Oauth is being
(mis)used for plain authentication , we want to deal with that, and OpenID
isn't appaently satisfying the need of the folks doing this. Is that
essentially correct?
What is the use case that the minimal OIDC implementation doesn't solve?
Is the problem that people want to use existing OAuth implementations and they
would rather use/extend them than go to OIDC?
On Friday, June 13, 2014 4:15 PM, Phil Hunt <phil.h...@oracle.com> wrote:
I think this is a false argument. What we desire to do or not do is not always
the WG's choice.
It’s not me asking an authentication enhancement. The issue is whether to
address improper authentication in the wild. Several of us all blogged about
this a while a go and the problem with improper use of 6749 for authentication
continues to grow.
Would it be better if we thought about this as the authentication “bug”?
I’m not sure everyone is on the same page regarding the term “authentication".
In none of the scenarios discussed are we talking about “performing”
authentication. We are talking about passing the authentication context from
the AS in a non-opaque form to the client where the client is the audience of
that information.
The authentication term is especially confusing because what developers *think*
they are doing is authentication. It is not.
Phil
@independentid
www.independentid.comphil.h...@oracle.com
On Jun 13, 2014, at 2:34 PM, Anil Saldhana <anil.saldh...@redhat.com> 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> 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
