Hi Brian, Hi Justin,
thanks for the quick feedback.
Here is the status from the last meeting:
http://www.ietf.org/mail-archive/web/oauth/current/msg12514.html
I tried to put a date to the milestone on the charter page.
When would this work be finished?
Ciao
Hannes
On 07/03/2014 04:58 AM,
Hi
I'm finding the answers from John interesting but I'm failing to
understand why refresh tokens are mentioned in scope of identifying the
specific client instances.
AFAIK refresh tokens would only go on the wire, assuming they are
supported, when a client exchanges a grant for a new
Implementations may/SHOULD bind refresh tokens to specific client instances.
Yes, it's possible that the client ID with dynamic registration is unique to
each client, but many of the token theft use cases include the possibility of
stealing the client ID too if you know you need to.
-bill
Part if the lack of consensus is lack of agreement on what mgmt is for. Until
that is resolved its hard to see what the timeline would be. Mgmt might be the
right call. Who knows.
For example i see credential rotation and client software update, and
deprovisioning as being events. I am not
Hi
On 03/07/14 16:40, Bill Mills wrote:
Implementations may/SHOULD bind refresh tokens to specific client
instances. Yes, it's possible that the client ID with dynamic
registration is unique to each client, but many of the token theft use
cases include the possibility of stealing the client ID
You might have a public client, the Flickr client for example (which uses OAuth
1 right now but it's a useful example) where the client ID is baked into the
install. In this case binding the token to the client ID means only that
someone who steals the token and tries to use it with a
Unfortunately I won't be in Toronto for #90 due to a conflict that week
with the Cloud Identity Summit http://www.cloudidentitysummit.com.
Hopefully nothing will come up from the IESG on the assertion bundle but I
trust Mike can handle it, if something requiring agenda time does surface
between
By the way, I will also not likely be in Toronto for most of the week due to
the same conflict (thanks a lot, Ping), but I might be able to make it in time
for the Thursday meeting depending on how travel arrangements get sorted out.
— Justin
On Jul 3, 2014, at 1:30 PM, Brian Campbell
I just started a new job and won't be there, probably not listening in on the
chat either
On Thursday, July 3, 2014 10:39 AM, Brian Campbell bcampb...@pingidentity.com
wrote:
Unfortunately I won't be in Toronto for #90 due to a conflict that week with
the Cloud Identity Summit.
I think you'll be okay time-wise. Since the JOSE + JWT drafts have been
requested to go as a bundle, I'll have to make sure I get it on a telechat
a little further out because of the amount of reading so the drafts get a
fair review. We still have to start the IETF last call on those drafts as
Mike,
Thanks for the updated JWT draft. I just read through it again and the
changes look good.
I noticed that privacy considerations were not mentioned. Should there be
any discussed for claims, claim sets, etc.? This is bound to come up in
the IESG review if it is not addressed. Sorry I
FWIW, I am very interested in the general concept of a lightweight or OAuth
based token exchange mechanism. However, despite some distaste for the
protocol, our existing WS-Trust functionality has proven to be good
enough for most use-cases, which seems to prevent work on token exchange
from
Hello!
Thank you for all of the updates to the JOSE drafts in the current bundle
in review. I appreciate all of the effort that went into the revisions!
As I understand it, there are a few general issues we need to work
through, then a few nits/requests are included on specific drafts.
Knowing
The explanation of on-behalf-Of and ActAs are correct in the document as
defined by WS-Trust, this may not be your desire or understanding but that is
how WS-Trust implementations should work
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 3, 2014
And I was suggesting that OAuth token exchange align with the WS-Trust
definitions or maybe even define totally new terms. But not use the same
terms to mean different things.
On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin tony...@microsoft.com
wrote:
The explanation of on-behalf-Of and
I’m lost, the terms defined in the oauth token-exchange draft are the same
terms defined in ws-trust and have the same definitions
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, July 3, 2014 12:02 PM
To: Anthony Nadalin
Cc: Vladimir Dzhuvinov; oauth@ietf.org
Subject:
I suspect it lines up. But Brian’s point may still be relevant. There is *long*
standing confusion of the terms (because many of have different english
interpretation than WS-Trust). Might be time for new terms?
Impersonate (or even personate) vs. delegate ?
Those terms differentiate between
On Thu, Jul 3, 2014 at 3:38 PM, Mike Jones michael.jo...@microsoft.com
wrote:
I can add something along these lines. Does that work for you?
*Privacy Considerations*
A JWT may contain privacy-sensitive information. When this is the case,
measures must be taken to prevent disclosure of
Replies inline…
From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
Sent: Thursday, July 03, 2014 11:56 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD
feedback on fifth spec of five
Hello!
Thank you for all of the
Thanks, Mike! In-line...
On Thu, Jul 3, 2014 at 4:03 PM, Mike Jones michael.jo...@microsoft.com
wrote:
Replies inline…
*From:* Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
*Sent:* Thursday, July 03, 2014 11:56 AM
*To:* Mike Jones
*Cc:* oauth@ietf.org
*Subject:* Re:
I don't think they do line up, at least not they way I read text from
http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html and
http://msdn.microsoft.com/en-us/library
and /ee748487.aspx http://msdn.microsoft.com/en-us/library/ee748487.aspx
and
Hello,
I just read through draft-ietf-oauth-jwt-bearer-09 and it looks good. The
only question/comment I have is that I don't see any mention of privacy
considerations in the referenced security sections. COuld you add
something? It is easily addressed by section 10.8 of RFC6749, but there is
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth 2.0 Dynamic Client Registration Protocol
Authors : Justin Richer
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth 2.0 Dynamic Client Registration Management
Protocol
Authors : Justin Richer
An updated OAuth Dynamic Client Registration spec has been published that
clarifies the usage of the Initial Access Token and Software Statement
constructs and addresses other review feedback received since the last version.
See the History section for more details on the changes made.
The
I pointed out a problem with the non normative text in sec 1.3 to Mike off list
quite a while go.
1.3. On-Behalf-Of vs. Impersonation Semantics
When principal A acts on behalf of principal B, A is given all the
rights that B has within some defined rights context. Whereas, with
ActAs the returned token is expected to be represented by the identity
described by this parameter
OnBehalfOf the request is being made by the identity described by this parameter
These terms have been pretty clearly defined in the WS specifications, I don't
understand the confusion. If section
Yes,
The the undifferentiated is initially differentiated by the user during
Authorization by having a code returned and then by exchanging the code for a
refresh token.
It however returns to being undifferentiated on subsequent authorization
requests.
This makes having sticky grants (only
This version of the spec contains these changes:
· Added a number of amr values.
· Renamed the code_id_token response type to code_for_id_token.
· Defined the code_for_id_token grant_type.
· Removed the min_alv request parameter, since it's actually just a
This is the first time this draft has come up on the list so people coming up
to speed is to be expected.
In WS-Trust the security tokens are not tied to a single representation.
/wst:RequestSecurityToken/wst14:ActAs
This OTPIONAL element indicates that the requested token is expected to
I’ve updated the token introspection draft with the intention that this
document become input for a new working group item.
http://tools.ietf.org/html/draft-richer-oauth-introspection-05
The changes are mostly minimal edits to the text and a few reference fixes. One
bigger change is the
I thought someone mentioned it already: in the example you might want to
send the request to /introspect instead of /register. It would be good to
see user_id returned in the example too to get a better sense of what it
really means (as I understand it, it's the username the user uses to sign
in
32 matches
Mail list logo
