To be precise SAML, Connect, and a4c provide Assertion-based authentication of
a claimant, by a Verifier (IdP) to a relying party (RP) when the RP and the
Verifier are not collocated ( i.e., they are connected across a shared network)
SP-800-63 sec 9
Typically we call this authentication (authn) though that may just be a bad
habit picked form SAML and other protocols use of the term.
It is true that people make horrible mistakes by ignoring the OAuth security
considerations and inappropriately use OAuth directly for inferring that the
presenter of the code or access token is the resource owner identified by the
resource.
I had sort of hoped that broad support and adoption of OpenID Connect would
help guide people in the correct direction.
If there is a need for a simpler IdP profile that is not interoperable across
IdP (Not Dynamic) the question is if developers will be more motivated to use a
profile of a larger standard as a starting point, or something presented as a
limited authentication extension to OAuth 2.
Clearly nothing will stop some people from rolling there own authentication.
The question is what solution will get the best traction.
My fear is that if developers see this as two competing standards they will use
that as justification to do there own thing rather than choose one.
At the end of the day what the profile looks like will likely be the same based
on the use case. The question is where will it be done and what do the
politics look like to developers.
That is the short term question.
John B.
On Jun 13, 2014, at 7: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.com
> phil.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
