Apologies, I may be speaking out of turn by not fully understanding the use
cases that this thread may be focused on. I’m interpreting the conclusions you
are proposing as general recommendations rather than addressing a specific case.
IMO the biggest general value of refresh is a periodic proof
You may be placing undue confidence in that gateway acting as a confidential
client but having no real security of its own and which could be easily duped.
Phil
> On Dec 2, 2018, at 3:43 PM, Aaron Parecki wrote:
>
> In this type of deployment, as far as OAuth is concerned, isn't the backend
While I generally agree with justin that moving everything to the back channel
is good, I worry that checking user login state may be more important.
What if upon refresh of a javascript client the AS would like to check the
validity of the current user session?
Many implementers solve the use
teless sessions, such
> functionality can be implemented by encoding user session information into
> the “code token".
>
> -DW
>
>> On Dec 6, 2018, at 11:51 AM, Phil Hunt > <mailto:phil.h...@oracle.com>> wrote:
>>
>> While I generally agree with jus
Yes. This was my worry.
Unless the oauth server is also an OIDC OP, it has no notion the user login
state. That state is held in cookies belonging to a federated provider.
The notion that javascript acting as a client and depends to the user login
state is what sets these cases apart. We hav
+1
Phil
> On Dec 18, 2018, at 10:14 AM, Torsten Lodderstedt
> wrote:
>
> Hi Hannes,
>
> while I think the current text needs some substantial work, I support the
> adoption of this draft as a working group document. I also think we need to
> carefully define the boundaries between the Secu
I have had a couple reviewers comment whether this means client authentication
is optional in Sec 3.12 for token refresh:
>* authentication of this client_id during token refresh, if
> possible, and
Do we not mean authentication of the client or some equivalent (e.g. looking at
brows
+1 to Mike and John’s comments.
Phil
> On Jan 19, 2019, at 12:34 PM, Mike Jones
> wrote:
>
> I also agree that “resource” should be a specific network-addressable URL
> whereas a separate audience parameter (like “aud” in JWTs) can refer to one
> or more logical resources. They are differe
I was a bit confused by how the 307 would work.
To confirm, Is the client having reached an MTLS optional endpoint being
redirected to an MTLS mandatory endpoint if the AT (or a cookie) is detected to
have a “cnf” claim in order to make the browser invoke MTLS?
Phil
Oracle Corporation, Cloud S
ell
> wrote:
>
> It would be more a client having reached a non-MTLS endpoint and is 307'd to
> an MTLS enabled endpoint.
>
>> On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt wrote:
>> I was a bit confused by how the 307 would work.
>>
>> To confirm, Is the
a cert.
>
> On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt <mailto:phil.h...@oracle.com>> wrote:
> If a client attempts to force mtls would typical tls terminators accept it
> enough to redirect?
>
> My worry is how optionality works in browsers. It seems like they have
Security and Identity Architect
@independentid
www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com
<mailto:phil.h...@oracle.com>
> On Feb 1, 2019, at 1:43 PM, Brian Campbell wrote:
>
> I guess I'm not clear what you are driving at.
>
> On Fri,
tificateRequest message is sent by the server in the handshake. And
> that message is sent in the optional case and the required case. Giving an AS
> a way to avoid the potentially bad UX for the end user is the impetus behind
> this whole discussion.
>
> On Fri, Feb 1, 2019 at 3
I feel I have to disagree. I agree that optionality is often complexity and
should be avoided. But, I think the optionality here is an agility feature
allowing mtls to work across a diversified market of different types of tls
terminators with varying capability. Lack of appropriate discovery/o
l remark. While I can certainly appreciate a
> desire to keep things simple, I do regret that this thread took a turn
> towards personal. Whether it was the intent or not, there's an impact.
>
>
>
>> On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt wrote:
>> I feel I have
+1 to Brian’s recommendations.
The recommendations provide practical help especially to facilitate real world
migration where bearer and non-bearer must co-exist without confusing end users.
Phil
> On Feb 20, 2019, at 7:10 AM, Brian Campbell
> wrote:
>
> The objective is to allow the AS to
+1 to using same authentication requirements as for token endpoint.
Phil
> On Mar 11, 2019, at 10:27 AM, George Fletcher
> wrote:
>
> +1
>
> to using the same client authn method as for the /token endpoint
>
>> On 3/11/19 12:31 PM, Brian Campbell wrote:
>>
>>
>>> On Mon, Mar 11, 2019 at 1
Question. One of the issues that Justin Richer’s signing draft tried to address
was url modification by tls terminators/load balencers/proxies/api gateways
etc.
How do you see this issue in dpop? Is it a problem?
Phil
> On Apr 3, 2019, at 9:01 AM, George Fletcher
> wrote:
>
> Perfect! Tha
s have to ensure the authorization (and subsequent
user authentication) occur over MTLS? Can the app provide its own key for MTLS
or can it ask that an embedded X.509 cert be used (assuming one is available)?
Are there any platform issues or best practices?
Phil Hunt | Cloud Security and Ident
at’s why work towards an application
> level PoP mechanism has been started - DPoP.
>
> best regards,
> Torsten.
>
>> Am 02.05.2019 um 20:41 schrieb Phil Hunt :
>>
>> I was wondering if anyone had any recommended MTLS best practices for mobile
>> apps and native
ay be able to answer.
>>
>>
>>
>> Should MTLS be added to a future version of the Native Apps BCP? If the
>> answer is “no”, why not?
>>
>>
>>
>> Ciao
>>
>> Hannes
>>
>>
>>
>>
>>
>> From: OAut
We looked at giving clients a public client id they could use to perform an
authorize with scope “dcr” to get an AT to be used as an IAT.
While it works it seems like overkill. The main risk with the DCR endpoint is
generating too many IDs ... a DoS issue primarily since having an ID is not
au
nice complement to our MTLS Token Binding
approach as well.
Thanks,
Phil Hunt | Cloud Security and Identity Architect
Oracle Corporation, Oracle Cloud Infrastructure
@independentid
www.independentid.com
phil.h...@oracle.com
___
OAuth mailing list
I disagree at this point that making changes to make oauth more restful is a
good thing. Doing so either means breaking changes or adding options that mean
unnecessary complication.
When oauth started rest was not the mandate. The current standard supports all
kinds of http services and that m
+1
Thanks Nat. These are important points.
Phil
Sent from my phone.
On 2013-01-30, at 18:59, Nat Sakimura wrote:
> OAuth did not talk make distinctions or talk about HTTP methods because of
> two reasons:
>
> (1) Browser in the middle with HTTP redirect constraint.
> (2) The protected res
sible.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
> Here are my notes.
>
> Participants:
>
> * John Bradley
> * Derek Atkins
> * Phil Hunt
> * Prateek Mishra
> * Hannes Tschofenig
> * Mike
gt; I'll repeat the use case for Flickr, which requires OAuth 1.0a type
> capabilites that OAuth 2 does not provide. Simply stating "move to HTTPS" is
> not a viable response here.
>
> From: Torsten Lodderstedt
> To: William Mills
> Cc: Mike Jones ; Jus
t;> capabilites that OAuth 2 does not provide. Simply stating "move to HTTPS"
>> is not a viable response here.
>>
>> From: Torsten Lodderstedt
>> To: William Mills
>> Cc: Mike Jones ; Justin Richer
>> ; Phil Hunt ; IETF oauth WG
>>
Are you advocating TWO systems? That seems like a bad choice.
I would rather fix scope than go to a two system approach.
Phil
Sent from my phone.
On 2013-02-28, at 8:17, John Bradley wrote:
> While scope is one method that a AS could communicate authorization to a RS,
> it is not the only o
Personally I am starting to feel strongly that access tokens should be highly
contextual and therefore tightly bound to specific resources.
It seems to me trust will get incredibly complex if we start federating access
tokens. My belief is that uma needs to still chain to local authorization
s
t one of those.
>
> It would probably make sense to try and build a profile of JWT specifically
> for OAuth access tokens (though I suspect there are some turtles and dragons
> in there), which might be the appropriate place to define/register a scope
> claim.
>
>
>
scope is
>> probably not one of those.
>>
>> It would probably make sense to try and build a profile of JWT specifically
>> for OAuth access tokens (though I suspect there are some turtles and dragons
>> in there), which might be the appropriate place to define/re
mplementations need different information for the
> RS to act on.
> Recommendations are fine but defining a field called scope and passing on
> exactly the scopes the client was granted is not going to work for everyone
> for lots of good reasons.
>
> John B.
> On 2013-02-28, at 8:24 AM
t define JWT's use for access tokens for the RS.
>
> Bottom line JWT is for more than access tokens.
>
> John B.
>
> On 2013-02-28, at 9:28 AM, Phil Hunt wrote:
>
>> Are you saying jwt is not an access token type?
>>
>> Phil
>>
>> Sen
Yes. That is my understanding.
Phil
Sent from my phone.
On 2013-02-28, at 9:49, Justin Richer wrote:
> OK, so it still runs the signature over HTTP elements (query, url, headers,
> etc) but all of the structured components are *communicated* via a JWT/JOSE
> structure. That makes sense to m
formation is not
> communicated to the RS and checked against what the resource owner accepted?
>
> Then, a secondary question is what the right mechanism is.
>
> Ciao
> Hannes
>
>
> On 02/28/2013 07:29 PM, Phil Hunt wrote:
>> What people are doing now is ofte
I should be in orlando at 7:30ish if anything is happening in the evening.
Phil
Sent from my phone.
On 2013-03-02, at 16:12, Anthony Nadalin wrote:
> I thought it was Sunday
>
> -Original Message-
> From: jose-boun...@ietf.org [mailto:jose-boun...@ietf.org] On Behalf Of Barry
> Leib
;
> JSON Web Token (JWT) A string representing a set of claims as a JSON
> object that is encoded in a JWS or JWE, enabling the claims to be
> digitally signed or MACed and/or encrypted.
>
>
> So OAuth or other profiles may define claims to go in a JWT, but the JWT
&g
ping between scope and audience,
>> but in reality the RS could expose multiple APIs at the same endpoint.
>> Granted the RS could extract the audience field based on a fully qualified
>> scope, but it just seems that claims, scopes, and audiences are each unique
>> and shoul
Mike,
It is my understanding there will be new draft (or a revision of the MAC draft)
that builds on the JWT draft to define a secure (MAC) token based on the
security requirements presentation I gave today.
I believe all/most of your questions should be addressed in the security draft:
http
It's a question of whether the jwt spec alone is used (in which case it needs
scope) or whether another profile for access tokens is needed.
Since scope is fundamental to oauth, i think it is part if the core set of
minimal attributes for access tokens. In fact i cab envision cases where
refe
I keep hearing a lot of questions about the JWT token draft and in particular
what should go in "sub" (Subject) claim. In the context of an access token,
there is confusion about whether it is the resource owner or the client.
Part of the problem is that JWT's can be used in multiple different w
There are a number of cases that all demand a more parsable scope.
One of the cases is multi resource scopes.
Would it not be reasonable to develop another draft that defines a simple json
structure that allows different uris to be matched with specific scope values?
I also wonder if registra
For parameters to token_endpoint_auth_method, the spec has defined
"client_secret_jwt" and "private_key_jwt". Shouldn't there be similar options
of SAML?
Shouldn't there be an extension point for other methods?
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
___
any other place that
> enumerates the various methods that a client can use to access the token
> endpoint.
>
> -- Justin
>
> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>> For parameters to token_endpoint_auth_method, the spec has defined
>> "client_secret_jwt
sonable for a
> client to specify which one it is going to use. In a closed system that may
> not be that useful but in a open system where the AS has a looser
> relationship to the client it is important.
>
> John B.
>
> On 2013-04-24, at 7:30 PM, Phil Hunt wrote:
>
ry or
> a published algorithm list by the server.
>
> -- Mike
>
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Phil Hunt
> Sent: Wednesday, April 24, 2013 3:55 PM
> To: John Bradley
> Cc: oauth@ie
> In many cases the client doesn't need to register parameters as they can be
>>> selected at run time once it knows what a server supports.
>>> The token endpoint authentication method was a bit of a special
>>> case where even though it could be
I find the text confusing regarding client auth.
>> "A client MAY use the "client_id" request parameter to identify itself
>> when sending requests to the token endpoint"
It seems to suggest client auth is optional due to the MAY when in fact it is
just referring to the client_id identifier whi
ly that a well-specified service discovery is important and we
> should, as a working group, help figure out what that looks like. As
> mentioned above, several of us already are. But I don't think it's helpful to
> conflate the registration and discovery processes and turn
d authorization
server wants them to use? If so what is it?
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-05-06, at 11:56 AM, Phil Hunt wrote:
> Justin,
>
> What you describe, though good intentioned, seems like a lot of complexity
> without getting
e a particular auth method to
> disallow the Authorization server from providing a weaker method to an
> attacker.
>
> This is a required parameter to allow a Authorization server to support high
> and low LoA clients dynamically.
>
> John B.
>
>
> On 2013-05
ents and this allows them to dynamic register those.
>
> If you allow 2 and 3 the one that need 3 will specify that.
>
> John
>
> On 2013-05-09, at 3:32 PM, Phil Hunt wrote:
>
>> Giving the client the choice lets the client choose lower LoA and downgrade.
>
ere the AS
> supports multiple methods.
>
>
> On 2013-05-09, at 3:58 PM, Phil Hunt wrote:
>
>> You seem to now be talking about SAML endpoints rather than OAuth endpoints.
>>
>>
>> I think you are confusing what the client gets back from the AS in te
The client auth type parameter issue needs to be resolved.
Phil
On 2013-05-09, at 16:23, John Bradley wrote:
> I believe the spec is fine as is.
>
> John B.
>
> On 2013-05-05, at 11:50 PM, Hannes Tschofenig
> wrote:
>
>> This is a Last Call for comments on
>> http://tools.ietf.org/html/dr
Maybe i am not being clear. I feel the parameter must not be in the dyn reg
request. The parameter should be in the response so that the client has no
choice and no ability to downgrade.
Phil
On 2013-05-09, at 16:37, Phil Hunt wrote:
> How does NOT allowing clients to choose authn t
gt; We are not getting anywhere on this. The parameter is required for dynamic
> registration of higher security clients at AS that support multiple
> token_endpoint authentication types.
>
> John
> On 2013-05-09, at 4:46 PM, Phil Hunt wrote:
>
>
>> Maybe i am not bei
It seems unfortunate that I have not gotten a chance to get into this level of
detail much earlier. But then, I guess that's what LC review is for! My
apologies for not getting many of these concerns to the WG much earlier.
Overall
---
I think dynamic registration is a critical part of
I am looking at the spec with fresh eyes?
Phil
On 2013-05-15, at 17:53, "Richer, Justin P." wrote:
> Phil, many thanks for the extremely thorough review! It is very useful
> indeed.
>
> My comments and responses to each point are inline.
>
> On May 15, 2013,
All,
In the dynamic registration draft, a new token type is defined called the
"registration access token". Its use is intended to facilitate clients being
able to update their registration and obtain new client credentials over time.
The client credential is issued on completion of the initia
My understanding is this is ok if during authorization, the client requested at
least "foo1 bar1 foo2" or "foo1 bar1 foo2 bar2" for example. The effect of
asking for a separate token is the client has two tokens with different scopes.
"foo1 bar1" and "foo2". This is actually nice because each
resent the client's registration.
>
> -- Mike
>
> From: Phil Hunt
> Sent: 5/17/2013 9:53 AM
> To: Mike Jones
> Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access
> Token - draft-ietf-oauth-dyn-reg-10
>
> Well why not just use the client toke
veral implementors in the Connect WG. There's an easy way
> to indicate that they don't expire, and a fairly straightforward way for them
> to be rotated (client does a GET on its client configuration endpoint url,
> with its registration access token as auth).
>
> -- Just
tion.
>
> Best regards,
> Don
> Donald F. Coffin
> Founder/CTO
>
> REMI Networks
> 22751 El Prado Suite 6216
> Rancho Santa Margarita, CA 92688-3836
>
> Phone: (949) 636-8571
> Email: donald.cof...@reminetworks.com
>
> -Original Message-
>
oper who probably
> doesn't want the client instances (say native clients) to be able to update
> the configuration directly. using the client secret credential for updates
> would break the separation. Registration my be done by the client itself or
> by a developer as a separate pr
s possible that in an
> extension we could allow for the developer portal to provide access tokens
> with perhaps a delet
e scope for the class rather than the instance if that is perhaps one of the
things you are looking for.
>
> I think the higher level management of classes of
Keep in mind there may be other changes coming.
The issue is that new developers can't figure out what token is being referred
to.
Phil
On 2013-05-20, at 8:09, Justin Richer wrote:
> Phil Hunt's review of the Dynamic Registration specification has raised a
> couple of issues that I felt we
Phil
On 2013-05-20, at 8:45, Justin Richer wrote:
>
> On 05/17/2013 07:29 PM, Phil Hunt wrote:
>> He's saying every client gets a registration token and a client token.
> What's a "client token", exactly? There are three potential places for OAuth
> tok
This draft isn't ready for LC.
Phil
On 2013-05-20, at 8:49, Justin Richer wrote:
> But also keep in mind that this is last-call, and that we don't really want
> to encourage avoidable drastic changes at this stage.
>
> -- Justin
>
>
> On 05/20/2013 11:21
On Behalf Of
> Justin Richer
> Sent: Monday, May 20, 2013 9:42 AM
> To: Phil Hunt
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration
>
> I, of course, disagree. But that's what we're trying to figure out as a
> working
just ignoring it the parameter.
There are concerns with this draft. I plan to make specific suggestions (some
breaking) later this week.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-05-20, at 10:51 AM, Phil Hunt wrote:
> -1
>
> The draft has features
nts to get the same client_id
> at all AS's they talk to (or otherwise be linked together), then you're going
> to need do specify a *whole* lot more than just registration. And it's not at
> all needed for what I (and others) see as the "normal" case for registr
+1
I also agree with Justin's comment on token_endpoint_auth_method.
Never-the-less, I did want to pass along the feedback that some were confused.
The expires_at, issued_at thing though is particularly confusing (though the
text may be clear) and is a higher priority issue in my opinion.
Phil
e expected that the endpoint be based upon SCIM and
> not something else like what has been done here.
>
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Monday, May 20, 2013 11:10 AM
> To: Anthony Nadalin
> Cc: Phil Hunt; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Propose
I had a conversation with Justin yesterday to try to come to a resolution
regarding my concerns about client instances and being able to associate client
instances that are issued for the same client software. I think we made some
progress.
Background:
In RFC6749, public clients, had a common
]
> Sent: Wednesday, May 22, 2013 1:35 PM
> To: Anthony Nadalin
> Cc: Phil Hunt; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration
>
> I'm not sure why you don't think it's in scope, it's in the working group's
> char
a
>>> non-breaking change by another spec if the working group eventually decides
>>> to pursue a route like the one proposed below. We don’t have to do it now
>>> for this to eventually come into being after deliberate consideration of a
>>> complete specification including these fe
I wanted to bring out a quick discussion to ask the question if it makes sense
to support implicit clients in dynamic registration.
By definition, implicit clients are unauthenticated. Therefore the only purpose
to register an implicit client is to obtain a client_id with a particular AS
instan
I have been struggling with the concept of an initial client credential covered
in the current draft (rev 10):
The Client Registration Endpoint MAY accept an initial authorization
credential in the form of an OAuth 2.0 [RFC6749] access token in
order to limit registration to only previously
gt;
>> I completely disagree with this assessment. The latest draft (which was just
>> posted) has new language describing what this token is and what it's for,
>> and I hope that will clear things up. But even so, let me try to address
>> your concerns in-line.
>>
don't
> understand what third party would be issuing these tokens. You seem to have
> a use case in mind but I don't think I understand it.
>
> John B.
>
> On 2013-05-24, at 7:26 PM, Nat Sakimura wrote:
>
>>
>>
>> =nat via iPhone
>>
Justin,
Thanks. I think this resolved all of my syntax issues.
The lifecycle text is very helpful.
I still want to continue discussion on initial access and reg access. We can
address in other threads.
Thx
Phil
On 2013-05-24, at 14:10, "Richer, Justin P." wrote:
> New Dynamic Registrati
er extensions and use implicit, without
> having a server based redirect. Those can be as long lived as any native
> app. If clean up is an issue it is one for code flow as well.
>
> John B.
>
> On 2013-05-24, at 2:35 PM, Phil Hunt wrote:
>
>> I wanted to bring o
is generally "I'm a client and I
> don't have a client_id for an AS that I want to talk to".
>
> Between yours and Torsten's comments, though, I think a discussion under the
> security considerations is a good idea.
>
> -- Justin
>
> On 05/27/201
No different issue. I was concerned about the initial client assertion being
passed in as authen cred. It is a signed set of client reg metadata.
See we are confused. Hence my worry. :-)
Phil
On 2013-05-30, at 8:48, John Bradley wrote:
> I think Phil also had some processing reason why a Tok
some are confused about this.
Phil
On 2013-05-30, at 8:52, Phil Hunt wrote:
> No different issue. I was concerned about the initial client assertion being
> passed in as authen cred. It is a signed set of client reg metadata.
>
> See we are confused. Hence my worry. :-)
>
>
parameters makes no difference to you. The assertion
> profile only uses POST parameters for the assertion rather than headers so
> that should not be an issue for that authentication method.
>
> John B.
>
> On 2013-05-30, at 11:52 AM, Phil Hunt wrote:
>
>> No differ
field (if others agree), but I'm not OK with defining
> assertion semantics there. I'm also not OK with defining assertion semantics
> in the Initial Registration Token. Both of these are too implementation
> specific, and from the client/developer's perspective these token
he permissions.
>
> They are both oauth access tokens.
>
> On 2013-05-30, at 12:02 PM, Phil Hunt wrote:
>
>> Seriously. The new dyn reg draft introduces two new tokens. The initial reg
>> token and the registration access token.
>>
>> As for the latter, the reg ac
nt credential expiry, why not simply require the client to update
its registration before it expires? Why have a long-lived "registration access
token" that has to be managed as well?
Maybe now I am completely confused?
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
s flow, but I think
> that's far more complicated than an endpoint saying "here's a token, go use
> it", personally. Besides, not all clients have credentials at the token
> endpoint, so it's a bit of a non-starter for a large class of clients.
>
> -- Justin
see any reason to change it.
>
> -- Justin
>
> On 05/30/2013 02:56 PM, Phil Hunt wrote:
>> It's hard to say what the best solution here is regarding clarifications
>> until we get clarity on the issue of registration access token.
>>
>> I don't thin
results.
>
> I will admit that it was a little strange when I first pulled the
> TokenServices reference into our RegistrationEndpoint class, but doing so
> greatly simplified everything else. I can see the desire to have an
> ideological purity of "all tokens come from the t
Phil
On 2013-05-30, at 16:11, "Richer, Justin P." wrote:
> Comments inline, marked by [JR].
>
> From: Phil Hunt [phil.h...@oracle.com]
> Sent: Thursday, May 30, 2013 5:25 PM
> To: Richer, Justin P.
> Cc: John Bradley; oauth@ietf.org WG
> Subject: Re: [OAUTH-WG
omething that's already in the draft.
>
> -- Justin
>
> From: Phil Hunt [phil.h...@oracle.com]
> Sent: Thursday, May 30, 2013 7:31 PM
> To: Richer, Justin P.
> Cc: John Bradley; oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-r
lient and server. Either you end up with public clients getting
> secrets they shouldn't need or with granting clients access to the
> client_credentials flow when they shouldn't actually have it. Plus it adds
> extra round trips which don't buy you anything.
>
> --
; I believe that I've already pointed out how the solutions you've proposed so
> far won't work in practice, for various reasons, many of which have already
> been brought up and discussed previously. If you have another way for the
> client to get its Registration Acces
n-normative editorial changes that I need to make, thanks to feedback from
> a few folks.
>
> Again, thanks for your thorough review, Phil, and I look forward to future
> feedback.
>
> -- Justin
>
> On 05/31/2013 12:28 PM, Phil Hunt wrote:
>> I disagree.
>>
stion is: how do you get the access token to access
> the created resource (IE: the Registration Access Token)? You can't use the
> client_credentials flow for a client with no credentials!
>
> -- Justin
>
>
> On 05/31/2013 12:58 PM, Phil Hunt wrote:
>> Yes. I spe
work.
>
> -- Justin
>
> On 05/31/2013 01:56 PM, Phil Hunt wrote:
>> Well the only client that wouldn't have a credential is an implicit client.
>> An implicit client is transient and so would never update.
>>
>> Besides, as i have stated, implicit clients s
1 - 100 of 668 matches
Mail list logo
