let's not this disagreement over the need & relevance of a4c be
conflated with the age-old blurriness between authz & authn - in no way
are the two related
paul
On 6/13/14, 7:50 PM, John Bradley wrote:
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
<mailto: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 <http://www.independentid.com/>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On Jun 13, 2014, at 2:34 PM, Anil Saldhana <anil.saldh...@redhat.com
<mailto: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
<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 <mailto: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
