that authorization server trusts. Thus,
I would like to propose the text change as:
3.4. Client Credentials
When requesting access from the authorization server, the client
identifies itself using its authorization-server-verifiable client
credentials.
--
Nat Sakimura (=nat)
http
that this could be included in OAuth 2.0 as it will help
build identity layers on OAuth 2.0 that works for mobile web browsers etc.
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
OAuth mailing list
OAuth@ietf.org
https
for choosing whether a parameter MUST, MAY or MUST NOT be
provided indirectly?
The example doesn't match the text as it directly include a 'client_id'
parameter.
Allowing any parameters to be provided indirectly sounds more sensible.
--
James Manger
--
From: Nat Sakimura
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
explicitly say request_url MUST
NOT appear in a file.
--
James Manger
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
...@aol.com wrote:
+1 for a defined extension mechanism
maybe I didn't understand but I would have thought the pape:error would
be...
pape:error=Invalid max_auth_age format.
does the message itself need to be namespaced?
Thanks,
George
On 6/8/10 12:45 AM, Nat Sakimura wrote:
Defining
also very easy to describe and
understand conceptually.
--
John Panzer / Google
jpan...@google.com / abstractioneer.org http://www.abstractioneer.org/ /
@jpanzer
On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura sakim...@gmail.com wrote:
I fully agree on it.
Instead of doing as a flow
we now do not have to sign the request. This simplifies
the implementation.
Dirk.
--
John Panzer / Google
jpan...@google.com / abstractioneer.org http://www.abstractioneer.org//
@jpanzer
On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura sakim...@gmail.com wrote:
I fully agree
It is my understanding that access token response may contain other
parameters than what is stated there.
Sometimes, mutually understanding server and client may want to
exchange other parameters on top of it and is legitimate, IMHO.
Is this understanding correct?
--
Nat Sakimura (=nat)
http
by the JavaScript and the server.
___
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
--
Nat
declaring a new parameter for the relevant endpoints.
EHL
On 6/7/10 7:53 PM, Nat Sakimura sakim...@gmail.com wrote:
I fully agree on it.
Instead of doing as a flow, defining request_url as one of the core variable
would be better.
The question then is, whether this community accepts the idea
I was wondering when you suggested to write an I-D about the request
by reference (which started as mobile WebApp flow), you wanted it for
the IPR reason or meant that it should be separate from the core. To
cover both case, I have submit the I-D
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
On Mon, Jun 21, 2010 at 10:26 PM, Ben Laurie b...@google.com wrote:
On 21 June 2010 14:22, Nat Sakimura sakim...@gmail.com wrote:
Hi Dirk,
In addition to Ben's questions, I have another. For X.509, you seem to
be using DER. How do you express the entire certificate chain using
DER
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
3.2. Error Response
Would it not be better to be something like below?
3. Obtaining End-User Authorization
3.1. Authorization Request
3.2. Authorization Response
3.3. Error Response
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
Magic
Signatures so that it does not contain newlines do?
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
On Wed, Jul 21, 2010 at 5:26 PM, Nat Sakimura sakim...@gmail.com wrote:
Hi Dirk,
Inline:
On Tue, Jul 20, 2010 at 9:22 AM, Dirk Balfanz balf...@google.com wrote:
On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Hi Dirk,
I have some questions
the
original text.
Also, with Sign + Encrypt, you can store the decrypted text and still
verify the
integrity of the data at a later date, but with Encrypt + Sign, you cannot.
Thus, to me, Sign + Encrypt seem to be a better approach.
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
)
Why not
base64url_encode(JSON(payload,envelope,signature)
It probably is less hassle in terms of coding. (It is true that some
parameters gets base64url encoded twice but
BTW, some of the envelope parameters such as alg needs to be signed as
well to thwart the algorithm replacing attack.
--
Nat
On Wed, Jul 28, 2010 at 5:43 AM, Dick Hardt dick.ha...@gmail.com wrote:
On 2010-07-27, at 12:34 AM, Nat Sakimura wrote:
I have a fundamental question.
While separating signature and payload by a dot . seems ok,
I still have not the answer for the question why not make everything
into JSON
On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz balf...@google.com wrote:
On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura sakim...@gmail.com wrote:
I have a fundamental question.
While separating signature and payload by a dot . seems ok,
I still have not the answer for the question why
certificates (chain as well)?
=nat
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
]
TOC
8.
Acknowledgements
[TODO]
TOC
9.
References
TOC
9.1.Normative References
[RFC2119]
Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP14, RFC2119, March1997 (TXT, HTML, XML).
[RFC3447]
Jonsson, J. and B. Kaliski, Public-Key Cryptography Standard
fcore...@pomcor.com, Marius Scurtescu
mscurte...@google.com, Justin Richer jric...@mitre.org
Cc: oauth@ietf.org oauth@ietf.org, Karen P. Lewison
kplewi...@pomcor.com, Nat Sakimura (n...@sakimura.org) n...@sakimura.org,
John Bradley ve7...@ve7jtb.com
Date: Wednesday, January 5, 2011, 5:18 PM
fcore...@pomcor.com, Marius Scurtescu
mscurte...@google.com, Justin Richer jric...@mitre.org
Cc: oauth@ietf.org oauth@ietf.org, Karen P. Lewison
kplewi...@pomcor.com, Nat Sakimura (n...@sakimura.org) n...@sakimura.org,
John Bradley ve7...@ve7jtb.com
Date: Wednesday, January 5, 2011, 5:18 PM
/listinfo/oauth
__**_
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/**listinfo/oauthhttps://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
to cope with this.
regards,
Torsten.
Am 22.10.2011 16:00, schrieb Nat Sakimura:
Hi.
Just a clarification:
Although my expired draft is 'request by reference', what was proposed
through it at the iiw really is a generalized JSON based claim request
capability. It could be passed by value
clients and servers
to handle OAuth request parameters differently than for standard OAuth
requests. Introducing the JSON based claim request capability to OAuth would
be a way to cope with this.
regards,
Torsten.
Am 22.10.2011 16:00, schrieb Nat Sakimura:
Hi.
Just a clarification
.
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
generators but
stopped short of listing them.
The second item, I read as defining the strength, giving the necessary and
desired bounds for a collision probability of two generated values.
Igor
On 2/2/2012 4:25 AM, Nat Sakimura wrote:
hi.
The rev. 23 has a normative change in section
of cryptographically-strong pseudo-random generators
but
stopped short of listing them.
The second item, I read as defining the strength, giving the necessary
and
desired bounds for a collision probability of two generated values.
Igor
On 2/2/2012 4:25 AM, Nat Sakimura wrote:
hi.
The rev. 23
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https
Forgot to cc the oauth list on this, so here it goes!
=nat
-- Forwarded message --
From: Nat Sakimura sakim...@gmail.com
Date: Tue, Feb 7, 2012 at 12:46 PM
Subject: Comments on Section 10.10 of OAuth 2.0
To: i...@ietf.org
Dear Sir/Madam:
Attached below, please find the comment
___
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
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http
de Medeiros [mailto:br...@google.com]
Sent: Thursday, March 15, 2012 2:12 PM
To: Eran Hammer
Cc: Nat Sakimura; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
On Thu, Mar 15, 2012 at 13:13, Eran Hammer
e...@hueniverse.com
wrote:
Ok. That's
@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
allows the attack.
Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui. You say that some
apps have issued a patch to fix it. Could you explain what the fix
was?
Francisco
--
*From:* Nat Sakimura
, at 17:30, Nat Sakimura sakim...@gmail.com wrote:
No. You do not need the sniffing in an unsecured connection.
But I am not sure if I should disclose the detail of the attack here in
the public list as that will open up a much more serious attack vector than
leaked passwords hash in recent
On Tue, Jun 26, 2012 at 1:54 AM, Lewis Adam-CAL022
adam.le...@motorolasolutions.com wrote:
[...snip...]
** **
I think the above just really drives home the fact that if OAuth is to be
used for securing enterprise API calls in a post-SOAP world, something
needs to be stated more explicitly.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman
+1
=nat via iPhone
On 2012/07/27, at 7:36, Dick Hardt dick.ha...@gmail.com wrote:
+1
On Jul 26, 2012, at 3:06 PM, Mike Jones wrote:
+1
Given that the current spec inadvertently broke both the SAML profile and
JWT profile, I believe we need to make these changes.
--
Let me know if we are meeting after the plenary.
=nat via iPhone
On 2012/07/30, at 16:39, Brian Campbell bcampb...@pingidentity.com wrote:
Is there any consensus about this?
On Mon, Jul 30, 2012 at 2:49 PM, Leif Johansson le...@mnt.se wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
are interested.
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
So, are we talking about the authz request or resource request?
=nat via iPhone
On Aug 15, 2012, at 5:49 AM, Justin Richer jric...@mitre.org wrote:
I would argue that it's exactly the process that you describe below that
makes my original comparison accurate. As a strawman example, OAuth2
that the application is hosted.
Hope these helps.
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth
://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
.
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
, or
a third party).
I would appreciate if you could clarify why is the case.
Best,
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
...@zte.com.cn zhou.suj...@zte.com.cn のメッセ�`ジ:
could be Resource owner?
*Tschofenig, Hannes (NSN - FI/Espoo) hannes.tschofe...@nsn.com*
发件人: oauth-boun...@ietf.org
2012-12-03 16:49
收件人
ext Nat Sakimura sakim...@gmail.com, Brian Campbell
bcampb...@pingidentity.com, oauth oauth@ietf.org
抄送
主题
assertions@ (Interestingly enough, Hui-Lan had brought
this up a couple of years ago.)
Igor
On 12/3/2012 3:58 AM, Nat Sakimura wrote:
I suppose, yes. I was reading it like that all the time.
Whether it is or not, if it is still ok, it might be better to
clarify it.
Word like
:39 PM, zhou.suj...@zte.com.cn wrote:
Why RO as an issuer is only theoretical today?
*Brian Campbell bcampb...@pingidentity.com*
2012-12-04 23:41
收件人
Nat Sakimura sakim...@gmail.com
抄送
zhou.suj...@zte.com.cn, oauth@ietf.org oauth@ietf.org
主题
Re: [OAUTH-WG] Assertion Framework - Why
the RO and AS functions shouldn't be precluded, but I would be
awfully confused if there were an RO/issuer in the picture and
*also* an AS that *doesn't* issue assertions.
Eve
On 5 Dec 2012, at 9:13 AM, Nat Sakimura sakim...@gmail.com wrote:
It is not OAuth, but Austrian eID
: internet-dra...@ietf.org
Date: Wed, Dec 12, 2012 at 11:46 PM
Subject: New Version Notification for draft-sakimura-oauth-meta-00.txt
A new version of I-D, draft-sakimura-oauth-meta-00.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.
Filename:draft
., The application/json Media Type for
JavaScript Object Notation (JSON), RFC 4627, July 2006.
[oauth-lrdd]
Mills, W., Link Type Registrations for OAuth 2,
October 2012.
Author's Address
Nat Sakimura (editor)
Nomura Research Institute
Email: sakim
FYI, I have been writing HoK for JWT/JWS Token by introducing a new claim
'cid'.
=nat via iPhone
Dec 14, 2012 11:56、zhou.suj...@zte.com.cn zhou.suj...@zte.com.cn のメッセ�`ジ:
Yep, could do it soon later.
Currently, I suggest a modification for
The token service is the assertion issuer; its
If I understand correctly, there are multiple devices with clients with the
same client_id involved and you want to revoke individual devices when
needed. You also do not want to store the password.
In a sense, the JWT is working like a device specific password with
distributed verifier. This is
claim is the URL that points to the
public key certificate of the registered client. The format of the
content that x5u points to is described in section 4.1.4 of the JSON
Web Signature.
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
: internet-dra...@ietf.org
Date: Wed, Dec 19, 2012 at 11:34 AM
Subject: New Version Notification for draft-sakimura-oauth-meta-01.txt
To: sakim...@gmail.com
A new version of I-D, draft-sakimura-oauth-meta-01.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository
talks
to.
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
context of
the “on behalf of”/delegation work that has been started
*From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Nat Sakimura
*Sent:* Tuesday, December 18, 2012 6:22 PM
*To:* oauth
*Subject:* [OAUTH-WG] cid claim in JWT
In OpenID Connect WG, we have been
this in the bigger context of
the “on behalf of”/delegation work that has been started
*From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
Of *Nat Sakimura
*Sent:* Tuesday, December 18, 2012 6:22 PM
*To:* oauth
*Subject:* [OAUTH-WG] cid claim in JWT
** **
In OpenID Connect WG
it means.
On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones michael.jo...@microsoft.comwrote:
What would the iss, prn, aud, and cid values represent in the boarding
pass example?
-- Mike
*From:* Nat Sakimura
*Sent:* December 19, 2012 9:32 PM
*To:* Mike Jones
*CC:* Anthony Nadalin, John Bradley
there.
-- Justin
On 12/18/2012 09:47 PM, Nat Sakimura wrote:
Justin,
In addition to instance_name and instance_description, I think we need
collision resistant instance_id which can be cryptographically linked to
the instance so that it can actually be authenticated, in a similar manner
SUB is totally undefined, if I remember correctly.
Nat
On Fri, Dec 21, 2012 at 1:39 AM, Anthony Nadalin tony...@microsoft.comwrote:
I can’t see how you think PRN is way under defined when SUB is not
** **
*From:* Nat Sakimura [mailto:sakim...@gmail.com]
*Sent:* Wednesday, December 19
*To:* Jeff Hodges; Nat Sakimura
*Cc:* IETF oauth WG
*Subject:* RE: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
What is the X.1252 definition?
-- Mike
*From:* Nat Sakimura
*Sent:* December 23, 2012 10:09 AM
*To:* =JeffH
*CC:* Mike Jones, IETF oauth WG
*Subject
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
I completely disagree with this assessment. Multi-tenancy will work
just fine (or even better) if everyone uses the same pattern. Telling
someone it might be three
.
** **
-- Mike***
*
** **
*From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
Of *Nat Sakimura
*Sent:* Wednesday, January 30, 2013 6:22 PM
*To:* John Bradley
*Cc:* oauth@ietf.org
*Subject:* [OAUTH-WG] Registration endpoints
://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
actions. This functionality
arose from discussions on the list about moving towards a more RESTful
pattern, and Nat Sakimura proposed this approach in the OpenID Connect
Working Group. This URL may be distinct from the Client Registration Endpoint
URL, but draft -05 makes no promises as to its
with that. Is this what you're suggesting?
As far as I understand, yes. That is what we discussed last Thursday
face to face.
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https
To: sakim...@gmail.com
Cc: m...@stateless.co
A new version of I-D, draft-sakimura-oauth-meta-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.
Filename:draft-sakimura-oauth-meta
Revision:02
Title: JSON Metadata for OAuth Responses
that.)
Best wishes,
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Nat Sakimura
Sent: Tuesday, February 12, 2013 9:11 AM
To: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG
Best wishes,
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat
Sakimura
Sent: Tuesday, February 12, 2013 9:11 AM
To: Justin Richer; oauth@ietf.org
Subject: Re
at
https://bitbucket.org/openid/connect/issue/747. I think that Nat's recent
comment there bears repeating on this list:
Nat Sakimura:
Not so sure. For example, PHP cannot get the JSON object form
application/json POST in $_POST.
It is OK to have a parameter like request that holds
...@ietf.org] On Behalf Of Nat
Sakimura
Sent: Tuesday, February 12, 2013 9:15 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
2013/2/13 Justin Richer jric...@mitre.org:
On 02/12/2013 11:30 AM, John Bradley wrote:
To some
Generally speaking, mapping PUT to replace and POST to change is an
acceptable practice so I am fine with it.
Now, what I still do not understand is why you think it is fine to do
PUT or POST and not DELETE. Doing PUT with empty content is almost the
same as DELETE. Could you explain?
=nat via
01:27 PM, Nat Sakimura wrote:
I am against the syntax of registration_access_url .
=nat via iPhone
Feb 13, 2013 3:37、Mike Jones michael.jo...@microsoft.com のメッセージ:
Then I think we've reached an acceptable resolution on this one. By having
the server return the registration_access_url upon
agreement on PUT and POST.
The general not in that a client can DELETE it's record is a implication I
don't like. I think that is for the server to decide and if it is not
actually deleting it then DELETE is the wrong verb to use.
John B.
On 2013-02-13, at 3:31 PM, Nat Sakimura sakim
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
When sending an update, a client MUST send all metadata fields returned
from the server in its initial registration or previous read or update
call, including its client_id. A server MAY replace any missing or
invalid fields with default values, or it MAY return an error as
described in the
/
___
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
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
[mailto:oauth-boun...@ietf.org] *On Behalf
Of *Nat Sakimura
*Sent:* Wednesday, February 20, 2013 7:58 AM
*To:* oauth@ietf.org; Richer, Justin P.; John Bradley
*Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
** **
Thanks Justin.
Even if we go flat rather than doing
*From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Nat Sakimura
*Sent:* Wednesday, February 20, 2013 7:58 AM
*To:* oauth@ietf.org; Richer, Justin P.; John Bradley
*Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
** **
Thanks Justin.
Even
that information can be retrieved as one aspect of
the operations on the client’s registration).
** **
-- Mike
** **
*From:* Nat Sakimura [mailto:sakim...@gmail.com]
*Sent:* Wednesday, February 20, 2013 8:53 AM
*To:* Mike Jones
*Cc
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
** **
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
and should be kept that way.
adam
*From:* Phil Hunt [mailto:phil.h...@oracle.com phil.h...@oracle.com]
*Sent:* Monday, March 11, 2013 9:25 AM
*To:* Nat Sakimura
*Cc:* Lewis Adam-CAL022; oauth@ietf.org WG
*Subject:* Re: [OAUTH-WG] JWT - scope claim missing
One thing that concerns me is that scope
://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
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
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org
] ___
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
--
Nat Sakimura (=nat)
Chairman
is
considerably improved.
[\quote]
- prateek
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
, it would be able to tell
without deep sniffing.
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
/oauthhttps://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
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
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
.
my 2c.
Nat Sakimura
2013/5/13 Stephen Farrell stephen.farr...@cs.tcd.ie
Hiya,
On 05/13/2013 09:04 AM, Hannes Tschofenig wrote:
Hi all,
the OpenID Connect had gained some experience with using version control
systems
for editing specifications (and the use of issue trackers), see
on the actual content. It's
not perfect either, but it's far from useless.
-- Justin
On May 13, 2013, at 9:08 AM, Nat Sakimura sakim...@gmail.com
wrote:
I am probably biased since I am the one who introduced ticket driven
version control to OIDF but it proved to be very valuable especially
1 - 100 of 404 matches
Mail list logo
