Actually, it may be the API's privacy policy so that it can state more
specific purpose than the site's.
So, we should not constrain it to be "site's".
Also, I might prefer "personal data" instead of "personal information" but
that might be just me.
Nat
2014-07-15 1:18 GMT+09:00 Mike Jones :
>
If we can reference individual drafts then
https://datatracker.ietf.org/doc/draft-bradley-oauth-pop-key-distribution/ is
an example of encryption to the client by the AS in sec 4.2.
If we want to reference an encryption example. I think signing is covered by
the assertion reference.
John B.
Hi Mike,
there is no problem referencing an individual draft particularly when
that reference gives some hint about how the stuff is used (particularly
when the referenced document might be a working group draft at the time
when the dynamic client registration document gets published as an RFC).
I'm not suggesting that we reference it. We reference JWT using the language I
already provided. I was just giving you another example of a signed JWT sent
to the authorization server, since you couldn't think of any off the top of
your head.
-Original Message-
From: Hannes Tschofenig
That would then be a reference to an individual draft ;-)
On 07/14/2014 07:55 PM, Mike Jones wrote:
> One example is when used as a signed request to the authorization server, as
> is done in http://tools.ietf.org/html/draft-sakimura-oauth-requrl-05.
signature.asc
Description: OpenPGP digital
One example is when used as a signed request to the authorization server, as is
done in http://tools.ietf.org/html/draft-sakimura-oauth-requrl-05.
-- Mike
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Monday, July 14,
Hi Mike,
sticking with working group document is fine.
However, the first example does not make sense to me.
[maybe my brain is a bit empty at the moment]
When is a JWT signed by the client and then sent to the Authorization
Server other than in the Assertion draft that I mention in the second
e
Fine with me. (I might change "the privacy policy" to "the site's privacy
policy".)
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Monday, July 14, 2014 4:25 AM
To: John Bradley; Mike Jones
Cc: Nat Sakimura; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dyn
I'd rather that we stayed with working group drafts in the examples. So I
would counter-propose the following text:
"The public key(s) referenced by "jwks_uri" (or contained in the "jwks") can be
used in a variety of use cases. For example, the signature of a JWT
[I-D.ietf-json-web-token] sign
There will be an OpenID meeting at IETF 90 on Sunday from 1-4. If you're
interested, please register at http://openid-ietf-90.eventbrite.com/.
-- Mike
___
OAuth mailing list
OAuth@ietf.org
ht
Here is a short summary of the recent conversations regarding the
dynamic client registration draft.
In a nutshell, we will have to put the document on the agenda for the
meeting.
Items discussed on the list:
* IPR confirmation
Include a statement indicating that this specification is a derivat
Here is the text from the OpenID Connect spec (as provided by Nat):
> policy_uri
> OPTIONAL. URL that the Relying Party Client provides to the End-User
>to read about the how the profile data will be used. The value of
>this field MUST point to a valid web page. The OpenID Provider
>
What about the following text:
jwks_uri
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18> .
"The public key(s) referenced by jwks_uri (or contained in the jwks) can
be used in a variety of use cases. For example, the AS can use the
indicated public key to verify a request to the
13 matches
Mail list logo
