+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 ch
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,
On 6/13/2014 7:15 PM, Phil Hunt wrote:
Would it be better if we thought about this as the authentication “bug”?
How can there be an authentication "bug" when OIDC has addressed it
backed by multiple implementations by different parties? Why don't you
see if OIDC addresses the minor optim
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 (au
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
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
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 s
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
+1
Thanks John.
Phil
> On Jun 13, 2014, at 12:11, John Bradley wrote:
>
> Subsequent to this email Phil and I have talked.
>
> There are two things that are deltas to connect in the spec.
>
> One is the ability to issue only a id_token from the token endpoint.
>
> The code grant_type requi
Subsequent to this email Phil and I have talked.
There are two things that are deltas to connect in the spec.
One is the ability to issue only a id_token from the token endpoint.
The code grant_type requires a access token in the response. If the WG wants
to define a new grant type that doesn
, June 13, 2014 9:27 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
For me it boils down to this:
OAuth deals with Authorization.
Authentication needs to be outside its realm - whether it is OIDC, SAML or
other protocols, it is fine.
The security
, 2014 9:22 AM
To: Prateek Mishra; IETF oauth WG
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
On 6/13/2014 11:46 AM, Prateek Mishra wrote:
> Thanks, Bill - I certainly appreciate the comment from an implementor
> who wasnt involved in the OIDC protocol design.
Best wishes,
-- Mike
From: Prateek Mishra [mailto:prateek.mis...@oracle.com]
Sent: Friday, June 13, 2014 9:55 AM
To: Mike Jones; Bill Burke; Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-
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
Phil - I want to hear who are those developers supporting a4c. You keep
saying developers developers. I am not one of them.
This mailing list has clearly shown total disregard for the a4c
proposal. Please try to accept the community sentiment and
unnecessarily don't extend this discussion int
On 6/13/2014 12:24 PM, Prateek Mishra wrote:
Excellent, now you have put your finger on the precise issue with OIDC -
lots of optional extensions and shiny trinkets and lack of a clear
definition of a core subset
for servers.
OIDC is a very clear specification. Your phrase "shiny trinkets"
I am going to address a few comments all together here:
1. John Bradley confirmed again yesterday, OIDC does not allow for
authentication only as part of the normal code flow and decided intentionally
not to address it. So to say OIDC has a solution is confusing.
OIDC has the solution if you w
To: Bill Burke; Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
Excellent, now you have put your finger on the precise issue with OIDC
- lots of optional extensions and shiny trinkets and lack of a clear
definition of a core subset for server
tf.org] On Behalf Of Prateek Mishra
Sent: Friday, June 13, 2014 9:24 AM
To: Bill Burke; Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
Excellent, now you have put your finger on the precise issue with OIDC - lots
of optional extensions and s
For me it boils down to this:
OAuth deals with Authorization.
Authentication needs to be outside its realm - whether it is OIDC, SAML
or other protocols, it is fine.
The security community has just muddled up things for end users,
implementors and adopters.
We need to start having clear cut
Excellent, now you have put your finger on the precise issue with OIDC -
lots of optional extensions and shiny trinkets and lack of a clear
definition of a core subset
for servers.
I realize its exciting for consultants, software and toolkit vendors to
have that sort of optionality, but in pra
On 6/13/2014 11:46 AM, Prateek Mishra wrote:
Thanks, Bill - I certainly appreciate the comment from an implementor
who wasnt involved in the OIDC protocol design.
My understanding of the discussion around a4c is one of a minimalist
extension to OAuth, not a full-featured one like OIDC.
One con
On 6/12/2014 4:18 PM, Phil Hunt wrote:
Phil
On Jun 12, 2014, at 12:50, 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 Open
Thanks, Bill - I certainly appreciate the comment from an implementor
who wasnt involved in the OIDC protocol design.
My understanding of the discussion around a4c is one of a minimalist
extension to OAuth, not a full-featured one like OIDC.
One concern I have heard expressed is that OIDC is so
On 06/13/2014 09:24 AM, Bill Burke wrote:
On 6/13/2014 10:21 AM, Anil Saldhana wrote:
On 06/12/2014 12:22 PM, Phil Hunt wrote:
One of the use cases is to return only a token that is NOT an access
token and is only an authentication assertion that is not opaque to
the client.
A key concern is
On 6/13/2014 10:21 AM, Anil Saldhana wrote:
On 06/12/2014 12:22 PM, Phil Hunt wrote:
One of the use cases is to return only a token that is NOT an access
token and is only an authentication assertion that is not opaque to
the client.
A key concern is clients do not always want to ask users fo
On 06/12/2014 12:22 PM, Phil Hunt wrote:
One of the use cases is to return only a token that is NOT an access token and
is only an authentication assertion that is not opaque to the client.
A key concern is clients do not always want to ask users for consent to access
their profiles or any oth
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.
Changin
+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 an
Phil
> On Jun 12, 2014, at 12:50, 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 pag
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
One of the use cases is to return only a token that is NOT an access token and
is only an authentication assertion that is not opaque to the client.
A key concern is clients do not always want to ask users for consent to access
their profiles or any other resource. They just want authentication
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 a4c draft proposal is 15 pages and will receive review from 100s of
engineers within the world's most advanced standards body the IETF.
It's a no b
the token itself, which is what I am
referring to.
Ciao
Hannes
-- Mike
-Original Message- From: OAuth
[mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt Sent:
Thursday, June 05, 2014 8:54 AM To: Hannes Tschofenig Cc:
oauth@ietf.org Subject: Re: [OAUTH-WG] Question regarding
draft
The response from the token endpoint has multiple parameters.
There is no reason to put information the client needs in the access token.
That creates more problems than it solves.
John B.
Sent from my iPhone
> On Jun 12, 2014, at 4:14 AM, Hannes Tschofenig
> wrote:
>
> Only a short no
Right, and the original question in this part of the thread was "why
bother with an ID token, why not just re-use the access token for both
purposes?"
Torsten's response below was in answer to that -- merging these two
would make the access token non-opaque to the client. This is
undesirable
The Id_token is audienced to the client. It is not sent to a resource server.
In a4c there may be no access token or resource server.
The id_token is not opaque to the client.
John B.
Sent from my iPhone
> On Jun 12, 2014, at 4:04 AM, Hannes Tschofenig
> wrote:
>
> Torsten,
>
> nobody
related to the
>> misuse of OAuth.
>>
>> -- Mike
>>
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
>> Sent: Thursday, June 05, 2014 8:54 AM
>> To: Hannes Tschofenig
>&
Only a short note: We haven't standardized a delegation mechanism yet
and the proposals we had discussed in the past did not require the
client to understand the content of the access token even for delegation.
Having said that I would like to note that it still required the AS to
send additional
The token introspection is useful when you use an access token that is
just a reference (instead of passing the values around using a JWT).
Using token introspection on the access token to get the content of the
access token in addition to the ID token will still get you the same
data twice (at le
Torsten,
nobody suggested that the access token would suddenly not be opaque to
the client.
The question therefore is whether the id token is not opaque to the
client. Is that the assumption?
On 06/05/2014 09:39 PM, Torsten Lodderstedt wrote:
>
> the access token is opaque to the client. That's
On 06/05/2014 09:20 PM, Bill Mills wrote:
> Can't agree more with the peril of overloading auth information into an
> access token.
Explain that a bit more, Bill.
I think we should to provide a design rational so that a reader who has
not participated in the standardization process understands t
oauth@ietf.org Subject: Re: [OAUTH-WG] Question regarding
> draft-hunt-oauth-v2-user-a4c
>
> You are correct. Just adding to access token would make a lot of devs
> happy and that certainly should be discussed.
>
> Two requirements issues:
>
> 1. A key use case is pass
: Bill Mills; Phil Hunt; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
>
> Examples?
>
> Am 05.06.2014 um 21:42 schrieb Anthony Nadalin :
>
> It’s great but some ways but also very limiting if you are counting on
> certain requirem
gt; has resulted in some of the most prominent security breaches related to the
> misuse of OAuth.
>
> -- Mike
>
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
> Sent: Thursday, June 05, 2014 8:54 AM
to:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
> Sent: Thursday, June 5, 2014 12:40 PM
> To: Bill Mills
> Cc: Phil Hunt; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
>
> +1
>
> the access token is opaque to the client. That&
oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
+1
the access token is opaque to the client. That's great! Let's keep it that way.
Am 05.06.2014 um 21:20 schrieb Bill Mills :
Can't agree more with the peril of overloading auth information i
Delegation
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Thursday, June 5, 2014 12:45 PM
To: Anthony Nadalin
Cc: Bill Mills; Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
Examples?
Am 05.06.2014 um 21:42 schrieb Anthony
No, it's great exactly *because* you can represent things in the access token
that make sense for your app/domain and it stays opaque to the parties who
shouldn't care: the clients. Access tokens aren't opaque to the AS (or PR),
because of OAuth's flexibility of token formats you can use what wo
Lodderstedt
> Sent: Thursday, June 5, 2014 12:40 PM
> To: Bill Mills
> Cc: Phil Hunt; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
>
> +1
>
> the access token is opaque to the client. That's great! Let's keep it that
&
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
+1
the access token is opaque to the client. That's great! Let's keep it that way.
Am 05.06.2014 um 21:20 schrieb Bill Mills
mailto:wmills_92...@yahoo.com>>:
Can't agree more with the peril of overloading aut
h [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
> Sent: Thursday, June 05, 2014 8:54 AM
> To: Hannes Tschofenig
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
>
> You are correct. Just adding to access token would make a lot
ginal Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
You are correct. Just adding to access token would make a lot of
Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
You are correct. Just adding to access token would make a lot of devs happy and
that certainly should be discussed.
Two requirements issues:
1. A key use case is passing auth ctx only. An access token
You are correct. Just adding to access token would make a lot of devs happy and
that certainly should be discussed.
Two requirements issues:
1. A key use case is passing auth ctx only. An access token means asking for
consent to access something. This causes many sites to loose new users. Auth
Hi Phil,
thanks for producing this document write-up. I have a somewhat basic
question regarding the document.
The id token contains the following mandatory information:
- sis: issuer
- sub: subject
- aud: audience
- iat: issued at
- exp: expiry
- auth_time: time when the end user was authe
56 matches
Mail list logo
