Great, thanks Kathleen. I'll get new drafts published soon(ish).
On Sun, Jul 20, 2014 at 6:18 AM, Kathleen Moriarty
kathleen.moriarty.i...@gmail.com wrote:
Thanks, Brian. That looks good to me.
Kathleen
On Sat, Jul 19, 2014 at 5:18 PM, Brian Campbell
bcampb...@pingidentity.com wrote
How about the following (which is intentionally similar to the text I just
put forth for your request for privacy consideration in
draft-ietf-oauth-jwt-bearer-09)?
A SAML Assertion may contain privacy-sensitive information and, to prevent
disclosure of such information to unintended parties,
:45 PM, Phil Hunt phil.h...@oracle.com wrote:
Should that be encrypted for the intended audience (aud) of the JWT which
may be the AS and/or the resource server?
Phil
On Jul 18, 2014, at 21:52, Brian Campbell bcampb...@pingidentity.com
wrote:
Sorry for the slow response on this Kathleen, my
'.
Best regards,
Kathleen
Sent from my iPhone
On Jul 19, 2014, at 1:00 AM, Brian Campbell bcampb...@pingidentity.com
wrote:
How about the following (which is intentionally similar to the text I just
put forth for your request for privacy consideration in
draft-ietf-oauth-jwt-bearer-09
Sorry for the slow response on this Kathleen, my day job has been keeping
me busy recently. And, honestly, I was kind of hopeful someone would
volunteer some text in the meantime. But that didn't happen so how about
the following?
A JWT may contain privacy-sensitive information and, to prevent
allow for a more flexible trust
model shortly.
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, July 03, 2014 12:04 PM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG
+1 to John's #3. The others could maybe be described in somewhat
abstract terms as examples of those higher level protocols that use
signing or encryption.
On Tue, Jul 8, 2014 at 12:33 PM, John Bradley ve7...@ve7jtb.com wrote:
In Connect these public keys are used to:
1 verify the signature of
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
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
-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 11:44 AM
*To:* Vladimir
.
-- Mike
*From:* OAuth [mailto:oauth-boun...@ietf.org oauth-boun...@ietf.org] *On
Behalf Of *Anthony Nadalin
*Sent:* Thursday, July 03, 2014 12:04 PM
*To:* Brian Campbell
*Cc:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00
I’m lost, the terms
Having difficulty finding consensus around a solution isn’t the same
thing as lack of interest in a solution. I think it would be very
premature to remove the Dynamic Client Registration Management
Protocol from the list of WG items.
On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig
.
On Thu, May 22, 2014 at 9:02 AM, John Bradley ve7...@ve7jtb.com wrote:
I was thinking of asking Brian Campbell as long as he doesn't let it go to
his head.
I expect Layer7 and others might also have an interest in such a thing.
John B.
On May 22, 2014, at 10:59 AM, Anil Saldhana
this a hard limit, or should it be guidance in the form
of RECOMMENDED or SHOULD?
On Friday, May 16, 2014 9:35 AM, Brian Campbell
bcampb...@pingidentity.com wrote:
Yeah, I agree with John here. There are a few good reasons to restrict
the length of the code_challenge. One is trying
Yes Sergey, it's to allow for support of unregistered clients. Typically
such clients will have some relationship established with a security token
service (STS) where they can obtain assertion grants and the AS trusts the
STS to issue such assertions. In that kind of scenario, the identity of the
, at 3:10 PM, Nat Sakimura sakim...@gmail.com wrote:
Now that I cannot remember what limit we were hitting, it might be a good
idea to remove the constraint and see if anyone protests.
What do you think?
Nat
2014-05-14 20:46 GMT+09:00 Brian Campbell bcampb...@pingidentity.com:
That too
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
...@salesforce.com]
*Sent:* Wednesday, May 14, 2014 9:39 AM
*To:* Anthony Nadalin
*Cc:* Phil Hunt; Brian Campbell; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering
Can you point to one publicly available or publicly documented
implementation of a4c?I've never seen
limitations as to the length of the sting to be
passed to it through URI and we did not want the challenges to be truncated
by that limit.
Best,
Nat
2014-05-13 6:56 GMT+09:00 Brian Campbell bcampb...@pingidentity.com:
And it'd give the AS some direct guidance on protecting itself from
tony...@microsoft.comwrote:
Please list the implementstions
*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
Yeah, it does depend on what it really is and why the length needs to be
restricted. That's what the other questions were really about.
Octets would be better than bytes, if that's what's intended.
On Mon, May 12, 2014 at 3:15 PM, Derek Atkins warl...@mit.edu wrote:
Brian Campbell bcampb
the upper bound for code_challange,
unless someone comes up with a really creative code challenge algorithm.
I will talk to nat about changing it to octets when I see him tomorrow.
John B.
On May 12, 2014, at 11:15 PM, Derek Atkins warl...@mit.edu wrote:
Brian Campbell bcampb
And it'd give the AS some direct guidance on protecting itself from crazy
long code_challenge values rather than relying on the client not to do
something creative.
On Mon, May 12, 2014 at 3:54 PM, Brian Campbell
bcampb...@pingidentity.comwrote:
Right but that's why I'm asking why not just put
I notice that code_verifier is defined as high entropy cryptographic
random string of length less than 128 bytes [1], which brought a few
questions and comments to mind. So here goes:
Talking about the length of a string in terms of bytes is always
potentially confusing. Maybe characters would
: Ping Identity logo] https://www.pingidentity.com/
Brian Campbell
[Enter Title]
@ bcampb...@pingidentity.com [image: phone] +1 720.317.2061 Connect
with us… [image: twitter logo] https://twitter.com/pingidentity [image:
youtube logo] https://www.youtube.com/user/PingIdentityTV [image:
LinkedIn
: Ping Identity logo] https://www.pingidentity.com/
Brian Campbell
[Enter Title]
@ bcampb...@pingidentity.com [image: phone] +1 720.317.2061 Connect
with us… [image: twitter logo] https://twitter.com/pingidentity [image:
youtube logo] https://www.youtube.com/user/PingIdentityTV [image:
LinkedIn
to any credential (like jwks) that doesn't have another means of
rotation. Or maybe just be a general expiration of the client's
registration.
On Wed, Apr 30, 2014 at 3:15 PM, Brian Campbell
bcampb...@pingidentity.comwrote:
As Mike and Torsten have said, and for the same reasons, I would also
PM, Brian Campbell wrote:
So JWT 3.1 is based entirely on, and is just a subset of, JWS Appendix
A.1. And I've got a test which validates that example in my JOSE library
https://bitbucket.org/b_c/jose4j:
https://bitbucket.org/b_c/jose4j/src/master/src/test/java/org/jose4j/jws
client authentication. Antonio's
email lead me to think about the authorization grant, which is obviously
a different story (which only happens to be in the same document because
of the document structure we came up with).
On 04/25/2014 09:57 PM, Brian Campbell wrote:
I absolutely agree
And those new drafts have now been published:
http://tools.ietf.org/html/draft-ietf-oauth-assertions-16
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-09
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-20
On Mon, Apr 28, 2014 at 12:41 PM, Brian Campbell bcampb
So JWT 3.1 is based entirely on, and is just a subset of, JWS Appendix A.1.
And I've got a test which validates that example in my JOSE
libraryhttps://bitbucket.org/b_c/jose4j:
https://bitbucket.org/b_c/jose4j/src/master/src/test/java/org/jose4j/jws/JwsUsingHmacSha256ExampleTest.java
And here's a
Note that the draft is showing an *octet sequence* with each individual
octet being shown as decimal value. It doesn't state anything about using
octal, the base-8 number system. Those octets also show unambiguously what
is being base64url encoded (including the line endings via 13, 10) - no
?
Ciao
Hannes
On 04/24/2014 02:30 PM, Brian Campbell wrote:
There is some discussion of that case in the assertion framework
document at
http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-6.3.1
Do you feel that more is needed? If so, can you propose some text
draft-ietf-oauth-jwt-bearer is only about interactions (client
authentication and JWT as an authorization grant) with the token endpoint
and doesn't define JWT style access tokens.
On Fri, Apr 25, 2014 at 12:51 PM, Bill Burke bbu...@redhat.com wrote:
Red Hat Keycloak [1] only supports basic
in the
assertion. Other elements within the assertion will, however, provide
enough information for the authorization server to make an authorization
decision.
Does this make sense to you?
Ciao
Hannes
On 04/24/2014 02:30 PM, Brian Campbell wrote:
There is some discussion of that case
2:59 PM, Brian Campbell wrote:
draft-ietf-oauth-jwt-bearer is only about interactions (client
authentication and JWT as an authorization grant) with the token
endpoint and doesn't define JWT style access tokens.
On Fri, Apr 25, 2014 at 12:51 PM, Bill Burke bbu...@redhat.com
mailto:bbu
-4.3
On Fri, Apr 25, 2014 at 3:04 PM, Bill Burke bbu...@redhat.com wrote:
On 4/25/2014 4:12 PM, Brian Campbell wrote:
IHMO getting everyone to agree on the specific claims etc. needed for a
standardized JWT access token is a bit of a rat's nest, which is why
there's not been much progress
I do not have, nor am I aware of any, IPR on any of the technology in
the document.
Couple of little things on the writeup:
Writeup for JSON Web Token (JWT) Profile for OAuth 2.0 Client
Authentication and Authorization Grants draft-ietf-oauth-saml2-
bearer-08 - should have
the resource owner.
It is possible to put garbage into the subject element when privacy
protection is needed for the resource owner case but that would need to
be described in the document; currently it is not there.
Ciao
Hannes
On 04/24/2014 12:37 AM, Brian Campbell wrote:
That thread
wrote:
Hi Brian,
does it sound reasonable for you to add text to the token introspection
endpoint regarding the use of the JWT bearer assertion for the token
introspection endpoint?
Ciao
Hannes
On 04/24/2014 12:58 AM, Brian Campbell wrote:
Just to pile on here - the Assertions draft(s) do
That thread that Antonio started which you reference went on for some time (
http://www.ietf.org/mail-archive/web/oauth/current/threads.html#12520) and
seems to have reached consensus that the spec didn't need normative change
and that such privacy cases or other cases which didn't explicitly need
While OAuth access tokens are a valuable application of JWT, might it also
be worthwhile to mention that JWT can and will be useful in other contexts?
Connect's ID Token is one such example:
http://openid.net/specs/openid-connect-core-1_0.html#IDToken
On Wed, Apr 23, 2014 at 5:55 AM, Hannes
Just to pile on here - the Assertions draft(s) do define client assertion
authentication only for the token endpoint (and register token endpoint
parameters). But it certainly doesn't preclude it from being profiled for
use elsewhere.
FWIW we used the token endpoint in our implementation of token
While I'm sure we can and will discuss the organization of the documents
for some
time, I wanted to reiterate that I believe the client credential management
part of this needs to be reevaluated (not just reorganized).
On Thu, Mar 6, 2014 at 9:37 AM, Anthony Nadalin tony...@microsoft.comwrote:
I might be suffering from a touch of confirmation bias but I think
this underscores what I was trying to say near the end of the JOSE
session in Vancouver during the key finding algorithm discussion.
Namely that finding a key is not the same as trusting a key and that
I'm concerned that explaining
on times and topics.
John B.
On Feb 26, 2014, at 1:57 AM, Anthony Nadalin tony...@microsoft.com wrote:
Agree, the OAUTH meeting should change to afternoon
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, February 25, 2014 2
Thanks Barry! I am very happy to hear that.
On Wed, Feb 26, 2014 at 9:01 PM, Barry Leiba barryle...@computer.org wrote:
Any idea, on the two Assertion Documents, if there is or will be any
feedback from the IESG and, if so, what form it might take?
I'm sorry that I haven't been able to get to
Any idea, on the two Assertion Documents, if there is or will be any
feedback from the IESG and, if so, what form it might take? There's a
chance #2 takes considerably less than 15 minutes, if there's no
feedback. And hopefully 15 mins will be sufficient, if there is some
feedback.
On Mon, Feb
Wasn't this originally announced with a different start time and Connect
and OAuth happening in the opposite order?
On Tue, Feb 25, 2014 at 10:23 AM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote:
Hi all,
Lucy organized a room for our informal discussion about OAuth (followed by
the
and an appropriate error
message.
* Todd Lainhart Rational software IBM Corporation 550 King Street,
Littleton, MA 01460-1250*
* 1-978-899-4705 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com
lainh...@us.ibm.com*
From:Brian Campbell bcampb...@pingidentity.com
To:oauth oauth
the on-line Internet-Drafts
directories.
This draft is a work item of the Web Authorization Protocol Working Group
of the IETF.
Title : Assertion Framework for OAuth 2.0 Client
Authentication and Authorization Grants
Authors : Brian Campbell
point, it seems to confuse (at least) a bit. In retrospective,
it would have been a better idea to copy the text.
The reference in section 2.1 is wrong, it should point to RFC 6749 (
http://tools.ietf.org/html/rfc6749#section-2.3).
regards,
Torsten.
Am 13.12.2013 00:42, schrieb Brian Campbell
It's a little dated now but I posted the slides from an talk on OAuth I
gave a while back that might be helpful:
http://www.slideshare.net/briandavidcampbell/oauth-101-secure-apis-2012-cloud-identity-summit-2012
On Thu, Jan 2, 2014 at 7:42 PM, Kaushal Shriyan kaushalshri...@gmail.comwrote:
Hi,
The second paragraph of section 2 of RFC 7009 [1] says that the revocation
endpoint must conform to the rules in section 3.1 of RFC 6749 (The OAuth
2.0 Authorization Framework) [2] but that section is about the
*Authorization Endpoint*, which doesn't make much sense to me. The resource
owner is
New versions of all three OAuth related assertion documents have been
published. Links to the htmlized drafts and change logs (mostly
clarification resulting from Shepherd review in early November) are listed
below. Thanks to Mike Jones for the preliminary review and updates/fixes.
Assertion
me
pre-drafts.
- mm
Matt Miller mamil...@cisco.com
Cisco Systems, Inc.
On Nov 5, 2013, at 4:11 PM, Brian Campbell
bcampb...@pingidentity.com
wrote:
Both after the plenary tomorrow and/or after JOSE on Thus work for
me.
Though not too much after as I've got other commitments later
On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote:
You write:
3. The JWT MUST contain an aud (audience) claim containing a
value that identifies the authorization server as an intended
audience. The token endpoint URL of the authorization
On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote:
Section 5 about Interoperability Considerations says:
Specific items that require agreement are as
follows: values for the issuer and audience identifiers, the location
of the token endpoint, and the
On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote
Item #2: You wrote:
Section 2.5.1.4 of Assertions and Protocols for the OASIS
Security Assertion Markup Language [OASIS.saml-core-2.0-os]
defines the AudienceRestriction and Audience elements
On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote:
Item #3: As in the draft-ietf-oauth-jwt-bearer-06 this part is extremely
fluffy, except for the case where it talks about the client-id. What exactly
do I put into the field in the case of an authorization
On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote:
Item #5: You write:
The Subject element MUST contain at least one
SubjectConfirmation element that allows the authorization
server to confirm it as a Bearer Assertion.
What do you mean
On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote:
Section 3:
Item #1: You wrote: Issuer
values SHOULD be compared using the Simple String Comparison
method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless
otherwise specified by
On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote:
Item #7+8: T I think you should combine the two items since they relate to
the same issue, namely when to include the AuthnStatement element.
Okay, #78 can be rolled up into one item.
There
are two questions:
On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote:
Item #10: You write:
10. The Assertion MUST be digitally signed or have a keyed message
digest applied by the issuer. The authorization server MUST
reject assertions with an invalid
On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote:
Security Consideration section:
I believe the section needs to say two things into addition to the reference
to the other specifications, which are already included in the security
consideration section:
a)
Some musings on
http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00
Abstract: ... allowing for fully stateless operation. -- saying that the
statelessness is on the AS side might avoid some confusion. The client is
still going to have to maintain state.
The kid is header rather
I just saw http://www.ietf.org/mail-archive/web/oauth/current/msg12218.htmlfrom
Hannes noting reviews on draft-ietf-oauth-json-web-token and was
surprised that mine wasn't included. So I went looking for it and
apparently I didn't actually send it to the list. But I did find it and am
including
Thanks for the review and feedback, Torsten, and apologies for the slow
reply. Responses to your questions are inline below and in some cases have
additional questions for you and/or the WG at large.
On Sat, Sep 28, 2013 at 7:36 AM, Torsten Lodderstedt torsten@lodderstedt
.net wrote:
Hi all,
Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be what
you're looking for?
On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso asa...@adobe.com wrote:
Hi *,
apologis to be back to this argument :).
Let me try to better explain one use case that IMHO would be really good
to
Regarding the second item about additional SAML related text - such
text already exists in the document in §5 [quoted and linked below].
It's unclear to me what else is being asked for here?
I'd like to request that some specific and concrete text be proposed,
if anyone believes the current
Not everyone has the time or inclination to follow and respond to all of this.
On Wed, Aug 28, 2013 at 10:01 AM, Anthony Nadalin tony...@microsoft.com wrote:
So I guess we should have different specifications for different use cases to
solve same requirements, I guess we should have done that
MAY use the client_id request parameter to identify
itself
when sending requests to the token endpoint.
regards,
Torsten.
Am 01.08.2013 15:57, schrieb Brian Campbell:
I thought I remembered that text from RFC 6749, section 3.1 as saying
that a *public* client MAY use the client_id
crowd.
** **
*From:* Brian Campbell [mailto:bcampb...@pingidentity.com]
*Sent:* Thursday, August 1, 2013 12:10 AM
*To:* Anthony Nadalin
*Cc:* Hannes Tschofenig; oauth mailing list
*Subject:* Re: [OAUTH-WG] Informal Dinner Discussion; Thursday @ 19:00
** **
That's a 35 minute
I thought I remembered that text from RFC 6749, section 3.1 as saying that
a *public* client MAY use the client_id request parameter to identify
itself...
Apparently that's not what it says. But I believe that was the intent - hat
a client with no means of authentication could identify itself by
Yes, that.
On Tue, Jul 30, 2013 at 4:46 PM, Richer, Justin P. jric...@mitre.orgwrote:
Yes, I agree that the giant stack of documents is intimidating and in my
opinion it's a bit of a mess with Messages and Standard split up (but I
lost that argument years ago).
FWIW, the 3 assertion documents are more targeted at cross domain type use
cases. For example, assuming a trust (and liklely legal) relationship is in
place, some corporate system acting as the client can trade a SAML token in
at the AS of a SaaS provider for an OAuth access token, which can then
I do not believe there are any open issues on the assertion documents.
The week before the IETF meeting is just a few days away. What needs to
happen to get these back with the IESG?
Note that the JWT assertions draft is dependent on the base JWT document,
which is yet to go to WGLC and in tern
I'll be attending.
I'd like to request some time to talk about the state of the assertion
drafts.
http://tools.ietf.org/html/draft-ietf-oauth-assertions
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer
Thanks,
Brian
On Wed, Jun
Thanks for the review Hannes. I've tried to constrain and/or clarify things
as much as I could. I am confident that those who deploy these
specifications are willing to take the steps described - there are real
deployments doing so now.
The introduction in the SAML document is intended to express
, Brian Campbell bcampb...@pingidentity.com wrote:
Just trying to close the loop on this thread (six weeks later, sorry). New
drafts were published last month that (hopefully) have more clear text
about the treatment of client_id. And it's been removed from examples where
it's optional.
http
New versions of all three OAuth related assertion documents have been
published. New document titles, URLs and change logs are listed below.
I've tried to address the comments and discuss issues from the IESG review
as well as subsequent discussion and decisions that took place in Orlando.
There
This little presentation from last year talks about OAuth mobile. In a
nutshell, it discusses using the authorization code grant and a redirect
uri with a custom scheme.
Adam-CAL022
*Cc:* Brian Campbell; WG oauth@ietf.org@il06exr02.mot.com
*Subject:* Re: [OAUTH-WG] JWT grant_type and client_id
The spec is a touch vague on that. I think the scopes should be in the
assertion and the client can use the scopes outside the assertion to
down-scope.
Having
Codifying a claim/attribute for scope that goes in the assertion is
something that's been discussed but never seemed to get sufficient
consensus regarding how to exactly to do it and if it really provided much
value.
On Fri, Mar 15, 2013 at 4:12 PM, Brian Campbell
bcampb...@pingidentity.comwrote
Yes, that is correct.
I'm working on new revisions of the drafts that will hopefully make that
point more clear.
On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022
adam.le...@motorolasolutions.com wrote:
Coming back to this … am I correct in that client_id is not required? We
are
interested to hear what others
think, particularly those who *aren't* tied into the OpenID Connect
protocol so much. (I don't want to pick a solution just because it's
familiar, if we need a solution at all.)
-- Justin
On Mar 11, 2013, at 6:35 PM, Brian Campbell bcampb...@pingidentity.com
wrote
I also don't think there's much value to it. Practically relative to the
additional complexity it'd bring along for the ride.
On Wed, Mar 13, 2013 at 4:17 PM, John Bradley ve7...@ve7jtb.com wrote:
It is a direct connection and not a browser redirect. I don't think there
is much value in
FWIW, the closely related OpenID Connect client registration draft does
have some support for doing this, which could maybe be borrowed. See
client_name in §2 at
http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadataand
the examples.
client_name: My Example,
, we don't want
to forget the web server clients that are multi user.
On 2013-03-11, at 10:49 PM, Brian Campbell bcampb...@pingidentity.com
wrote:
FWIW, the closely related OpenID Connect client registration draft does
have some support for doing this, which could maybe be borrowed. See
Likewise, I'll be arriving in Orlando ~3:30pm, if there's anything
happening later in the afternoon/evening?
On Sat, Mar 2, 2013 at 5:19 PM, Phil Hunt phil.h...@oracle.com wrote:
I should be in orlando at 7:30ish if anything is happening in the evening.
Phil
Sent from my phone.
On
I think John's point was more that scope is something rather specific to an
OAuth access token and, while JWT is can be used to represent an access
token, it's not the only application of JWT. The 'standard' claims in JWT
are those that are believed (right or wrong) to be widely applicable across
to authorization between AS and RS.
Hannes wanted to know why JWT didn't define scope. The simple answer is
that it is out of scope for JWT itself. It might be defined in a OAuth
access token profile for JWT but it should not be specific to MAC.
John B.
On 2013-02-28, at 8:44 AM, Brian Campbell
could be made the other way.
On Thu, Feb 28, 2013 at 12:03 PM, Brian Campbell bcampb...@pingidentity.com
wrote:
I'm not sure anyone really picked the titles for the bearer token
profiles. They just kind of evolved. And evolved in funny ways especially
when client authn to the AS was added
… maybe the RS’s of the
future will be good with this.
** **
adam
** **
*From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
Of *Brian Campbell
*Sent:* Thursday, February 28, 2013 1:03 PM
*To:* John Bradley
*Cc:* oauth@ietf.org WG
*Subject:* Re: [OAUTH-WG
itself. It might be defined in a OAuth
access token profile for JWT but it should not be specific to MAC.
John B.
On 2013-02-28, at 8:44 AM, Brian Campbell bcampb...@pingidentity.com
wrote:
I think John's point was more that scope is something rather specific
to an OAuth access token
at 3:02 AM, Sergey Beryozkin sberyoz...@gmail.comwrote:
On 20/02/13 11:45, Sergey Beryozkin wrote:
On 19/02/13 14:27, Brian Campbell wrote:
The scope of assertion based client authentication is only in OAuth and
only for the client calling the AS's token endpoint. Defining a general
HTTP auth
Yeah, in general the client identification/authentication is independent
from the grant being presented. There may be policy (maybe unidentified
clients aren't allowed) or other protocol details (like some kind of HoK
bound to the client, though that doesn't exist yet) that dictate more
The scope of assertion based client authentication is only in OAuth and
only for the client calling the AS's token endpoint. Defining a general
HTTP auth scheme for assertions would have a much broader scope and be much
more difficult to standardize.
On Tue, Feb 19, 2013 at 6:54 AM, Sergey
I do believe some face to face discussion amongst a smallerish group might
be valuable on this. I'll be in Orlando and plan on contributing to that as
much as I can. Thanks for organizing the lunch discussion Stephen.
I do feel that this conversation has strayed a bit and I'd like to clear up
one
Thanks for the feedback Prateek. I've tried to address some of you comments
and questions inline below.
On Wed, Feb 13, 2013 at 3:53 PM, Prateek Mishra
prateek.mis...@oracle.comwrote:
It would be helpful if the draft identified the various cases that are
intended to be supported. For example,
901 - 1000 of 1167 matches
Mail list logo
