The key for pop via the browser is different than the one between the client
and the RS. The key representation is likely to be the same but presentment
will likely be different.
This WG is focusing on OAuth tokens and assertion flows.
Getting a id_token with HoK for use in an assertion flo
Hi,
Does the WG plan to include OIDC id_tokens within the scope of the HOTK/POP
work? I've scanned through all of the existing HOTK/POP drafts and none make
any reference to id_tokens. Is this effort going to be scoped strictly to
access tokens?
I am at a cross road right now where I'm consi
Thanks Phil & Mike,
Would it possible to write this as a separate
"profile" of Connect and/or UMA? The reason I ask
is because a somewhat standalone document could be
useful in other deployment scenarios, such as an
Enterprise use-case, where some minimal OAuth2.0
"awareness" exists.
In this ca
The "re-auth" problem is an interesting one, the question of how does the
client know if the user new authentication matches the previous one for
something like mailbox access? What happens if the end user doesn't auth as
the same user? If you really need this I think Connect solves this well,
The "acr" claim (authentication context class reference) and the "acr_values"
request parameter are explicitly modelled on the SAML authentication context
work, but without the more complicated parts that didn't work out well in
practice. In this case, the request is just an ordered list of req
Thomas,
The intent was to be compatible with Connect (by request) but to solve only the
authentication issue. That would explain the overlap with UMA.
The issue (or bug?) we face is that OAuth Clients who continue to use 6749
alone, aren’t really authenticating users.
More importantly there i
Hi
I'm reviewing the way client authentication is expected to be done when
either SAML or JWT bearer assertion is used as a grant [1] which
corresponds to the case described in [2].
[1] says: "Authentication of the client is optional...".
Can someone please clarify how it can be optional giv
Phil,
I also just read draft-hunt-oauth-v2-user-a4c-02.
This proposal sounds awfully close to what UMA is
doing for consent management.
The Resource Owner (RO) in UMA has the option to
set access control policy (including expected the
authentication LOA of the user/client). The RO
also has the o
I'm reading the AC4 draft and I want to understand the problems it's actually
trying to solve, which isn't as clear as it could be in the prose. It looks
like it's extending OAuth to:
1) Allowing the client to specify a desired authentication level.
2) Giving the client an opaque identifier to
"We're still dealing with ws-federation passive profile in saml dominated
world. The oauth working group shouldn't repeat that sin."
Well said, Chuck, I couldn't agree more.
The world doesn't need two different OAuth-like SSO protocols and all the
confusion and interoperability problems that wou
"I had personally requested the OIDC community about six months ago to
describe some minimal subset which we could all reasonably implement. I was
told that the specification was "locked down" and fully debugged and so
on, so no changes could be made. Imagine my surprise to find that in the
final
Where is the confusion ?
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 14, 2014 10:59 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering
I know a number of people implementing
http://tools.ietf.or
12 matches
Mail list logo
