Re: [OAUTH-WG] Agenda requests, please

Unfortunately I won't be in Toronto for #90 due to a conflict that week with the Cloud Identity Summit . 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

[OAUTH-WG] Dynamic Client Registration Management Protocol (was Re: Agenda requests, please)

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 wrote: > > *

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

I agree that, at this point, debating the details of a4c is premature. SSO/authentication are not part of the WG charter and, as I've said before, I'd object to changing the charter to include it. Other than a small but vocal minority, I think it's fair to say that that's also been the prevailing s

Re: [OAUTH-WG] Token revocation - response status for valid token but incorrect client

Hi Pedro, I'm not sure it will exactly answer everything for you but there was a thread awhile back that started with a very similar question: http://www.ietf.org/mail-archive/web/oauth/current/msg12430.html On Wed, Jun 11, 2014 at 10:06 AM, Pedro Felix wrote: > Hi, > > In the context of RFC 70

Re: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect

e too long. On Thu, May 22, 2014 at 9:02 AM, John Bradley 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, 20

Re: [OAUTH-WG] Client authentication and assertion grants

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

Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03

make 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

Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03

On May 16, 2014, at 3:10 PM, Nat Sakimura 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 : &

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

ype. > > We're still dealing with ws-federation passive profile in saml dominated > world. The oauth working group shouldn't repeat that sin. > > -cmort > > > On Wed, May 14, 2014 at 2:40 PM, Anthony Nadalin wrote: > >> There are folks that are not implement

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

"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

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

wrote: > 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

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

rt within the OAuth working group will > focus on enhancing interoperability and functionality of OAuth > deployments, such as a standard for a token introspection service and > standards for additional security of OAuth requests. > > - > > Feedback appreciated. > > Ciao > Hannes & Derek &

Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03

t the reason for the limit was > that some platform had some 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 Campbe

Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03

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 wrote: > Right but that's why I'm asking why not jus

Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03

ing the code_verifyer size sets 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 Atkin

Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03

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 wrote: > Brian Campbell writ

[OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03

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

Re: [OAUTH-WG] [OT] Validation of JWE spec Appendix 1

> OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- [image: Ping Identity logo] <https://www.pingidentity.com/> Brian Campbell [Enter Title] @ bcampb...@pingidentity.com [image: phone] +1 720.317.2061 Connect with us… [

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

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 wrote: > As Mike and Torsten have said, and for the same reasons, I would also

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

Registration > Metadatahttp://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00 > > Since we have to do the last call for these two documents together we > are setting the call for **3 weeks**. > > Please have your comments in no later than April 25th. > > Ciao > Hannes

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

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 wrote: > Thanks Han

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

ore. As I mentioned in my original email we had only > discussed a related issue regarding 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 d

Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples

for those who > want to re-create the examples. > > What do you think? > > Ciao > Hannes > > > On 04/25/2014 03:03 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 th

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

ction-4.3 On Fri, Apr 25, 2014 at 3:04 PM, Bill Burke 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

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

> > > On 4/25/2014 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. >> >> &

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

ication profile what the contents of the > issuer and the subject fields are and so I don’t think we need to further > specify their contents beyond what’s already in the specs. > > -- Mike > > *From:* OAuth [mailto:oauth-bou

[OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

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 wrote: > Red Hat Keycloak [1] only supports basic auth for client aut

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

ich the access token is being > requested. > > When the client is acting on behalf of an anonymous user, as described > in Section 6.3.1, the Subject element MUST NOT be included in the > assertion. Other elements within the assertion will, however, provide > enough information for the auth

Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples

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 matt

Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples

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/src/master/src/test/java/org/jose4j/jws/JwsUsingHmacSha256ExampleTest.java And here's

Re: [OAUTH-WG] Assertions: Client authentication for non-token endpoints?

@gmx.net> 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 Campb

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

grant where the subject is > in most cases 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

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

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" " -> should have "" Does the answer to 14 need more explanation? T

Re: [OAUTH-WG] Assertions: Client authentication for non-token endpoints?

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

Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 Shepherd Write-up

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 Tscho

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

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

Re: [OAUTH-WG] IETF #89 OAuth Meeting Notes

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 wrote: > I'm not convinced th

Re: [OAUTH-WG] Discussion about Dynamic Client Registration Management Work

WFM too On Tue, Mar 4, 2014 at 6:13 PM, Phil Hunt wrote: > WFM > > Phil > >> On Mar 4, 2014, at 18:04, Hannes Tschofenig >> wrote: >> >> Hi all, >> >> at today's OAuth meeting I suggested to get together during the week to >> continue our conversation about draft-ietf-oauth-dyn-reg-management-0

Re: [OAUTH-WG] Correct use of jku claims in JWT/JWS bearer assertions

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 explainin

Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2

ed meetings. >>> >>> I don't know if the room is booked for something else after 3 but we could >>> likely find out. >> >> I can check - it would help if everyone agreed on times and topics. >> >>> John B. >>> >>> On Feb 26,

Re: [OAUTH-WG] Reaction to the current assertion pair {framework, SAML}

Thanks Barry! I am very happy to hear that. On Wed, Feb 26, 2014 at 9:01 PM, Barry Leiba 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 reviewing thi

Re: [OAUTH-WG] Draft Agenda

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 24,

Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2

own as early as is reasonable and changes can be avoided. On Tue, Feb 25, 2014 at 12:58 PM, John Bradley wrote: > Yes. > > Things change that's life. > > > > Sent from my iPhone > > On Feb 25, 2014, at 8:16 PM, Brian Campbell > wrote: > > Wasn

Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2

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 > t

Re: [OAUTH-WG] Another question on RFC 7009

turn an error_code of "invalid_request" and an appropriate error >> message. >> >> >> >> >> >> >> >> * Todd Lainhart Rational software IBM Corporation 550 King Street, >> Littleton, MA 01460-1250* >> >> >> * 1-978-899

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-assertions-14.txt

-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 Chuck Mortimore

[OAUTH-WG] Another question on RFC 7009

Greetings WG, In section 2.1 of RFC 7009, it says: "The authorization server first validates the client credentials (in case of a confidential client) and then verifies whether the token was issued to the client making the revocation request. If this validation fails, the request is

Re: [OAUTH-WG] Question on RFC 7009 OAuth 2.0 Token Revocation

6749 ( > http://tools.ietf.org/html/rfc6749#section-2.3). > > regards, > Torsten. > > Am 13.12.2013 00:42, schrieb Brian Campbell: > > 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 6

Re: [OAUTH-WG] Books or Tutorials to know about OAuth

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 wrote: > Hi, > > Are there tutorials

[OAUTH-WG] Question on RFC 7009 OAuth 2.0 Token Revocation

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 inv

[OAUTH-WG] New Assertion Drafts Published

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 Frame

Re: [OAUTH-WG] IETF WG Follow-up

t;>> >>>>>> On Tue, November 5, 2013 7:34 pm, Matt Miller (mamille2) wrote: >>>>>> A working lunch I can do in both cases, if real-time feedback is >>>>>> deemed >>>>>> worthwhile. I could also participate in a dinner

Re: [OAUTH-WG] IETF WG Follow-up

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 both days. What about a "working lunch" tomorrow after the plenary? I bet even Matt eats lunch... On Tue, Nov 5, 2013 at 3:28 PM, Matt Miller (mamille2) wrote

[OAUTH-WG] Security Considerations (was draft-ietf-oauth-saml2-bearer-17)

On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig 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) The specification

[OAUTH-WG] message digest and signature (was draft-ietf-oauth-saml2-bearer-17)

On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig 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 signature or keyed mess

[OAUTH-WG] AuthnStatement (was draft-ietf-oauth-saml2-bearer-17)

On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig 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 element. Okay, #7&8 can be rolled up into one item. > There > are two questions: > > Q1: Has the subject been au

[OAUTH-WG] issuer (was draft-ietf-oauth-saml2-bearer-17)

On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig 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 the application." >

[OAUTH-WG] Confirmation (was draft-ietf-oauth-saml2-bearer-17)

On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig wrote: > Item #5: You write: > > " > The element MUST contain at least one > element that allows the authorization > server to confirm it as a Bearer Assertion. > " > > What do you mean that the AS confirms that it is a bearer ass

[OAUTH-WG] Subject (was draft-ietf-oauth-saml2-bearer-17)

On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig 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 grant? Similar to sub in t

[OAUTH-WG] audience (was draft-ietf-oauth-saml2-bearer-17)

On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig 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 and elements and, > in addition to the URI reference

[OAUTH-WG] Interoperability Considerations (was draft-ietf-oauth-jwt-bearer-06)

On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig 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 key used to apply

[OAUTH-WG] audience (was draft-ietf-oauth-jwt-bearer-06)

On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig 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 server >

[OAUTH-WG] subject (was draft-ietf-oauth-jwt-bearer-06)

On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig wrote: > You write: > " >2. The JWT MUST contain a "sub" (subject) claim identifying the > subject of the transaction. The subject MAY identify the > resource owner for whom the access token is being requested. > > A.

[OAUTH-WG] issuer (was draft-ietf-oauth-jwt-bearer-06)

On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig wrote: > > Section 3: > > You write: > " >1. The JWT MUST contain an "iss" (issuer) claim that contains a > unique identifier for the entity that issued the JWT. Issuer > values SHOULD be compared using the Simple String Comp

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-06

Thanks for the review and feedback Hannes. There are a number of different items here and I think it'll be more productive to discuss them individually, so I'll partition this into a different threads for each general topic. I plan to do the same thing for your review of draft-ietf-oauth-saml2-bea

Re: [OAUTH-WG] [Openid-specs-ab] -00 of draft-bradley-stateless-oauth-client

k it's perfectly reasonable to expect an AS that wants stateless clients to make those kinds of changes. > I think it is worth discussing. Thanks, I'll see you in a few hours... > > On Nov 3, 2013, at 8:36 AM, Brian Campbell > wrote: > > Some musings on > http:/

[OAUTH-WG] -00 of draft-bradley-stateless-oauth-client

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

Re: [OAUTH-WG] Next Steps for the JSON Web Token Document

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 wha

Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts

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 wrote: > Hi all, > > here are my comments:

Re: [OAUTH-WG] Oauth Server to Server

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 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 have in the

Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts

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 wordin

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details

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 wrote: > So I guess we should have different specifications for different use cases to > solve same requirements, I guess we should have done that we OAuth and not >

Re: [OAUTH-WG] Authz Header + client_id in message body

t; > "A _public_ client 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

Re: [OAUTH-WG] Authz Header + client_id in message body

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

Re: [OAUTH-WG] Informal Dinner Discussion; Thursday @ 19:00

IETF 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 > &g

Re: [OAUTH-WG] Informal Dinner Discussion; Thursday @ 19:00

That's a 35 minute walk each way. Will MSFT be providing transportation? On Thu, Aug 1, 2013 at 8:52 AM, Anthony Nadalin wrote: > How about http://www.zollpackhof.de/english/restaurant/terrassen.html > > > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt

Yes, that. On Tue, Jul 30, 2013 at 4:46 PM, Richer, Justin P. wrote: > > 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). > __

Re: [OAUTH-WG] Using SAML for authentication *and* as Authorization Grants

Seems legitimate to me. In fact, initial versions of the draft sought to simplify things by restricting the audience restriction and subject confirmation to single elements but was expanded to allow for this kind of scenario. In my (somewhat limited) experience, however, support in SAML products f

Re: [OAUTH-WG] WG: SAML-like ActAs

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 b

Re: [OAUTH-WG] Agenda for IETF#87 Meeting

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 d

Re: [OAUTH-WG] Berlin IETF Meeting: Agenda Items?

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 26,

Re: [OAUTH-WG] Review of the assertion drafts

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

Re: [OAUTH-WG] JWT grant_type and client_id

ity for assertions? > > Phil > > On 2013-05-01, at 5:35, Brian Campbell 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&#

Re: [OAUTH-WG] JWT grant_type and client_id

e form payload is when the > client secret is empty or perhaps the client is not in the possession of > the secret. > > Does it make sense to completely drop a "client_id" parameter in the > example at [1] in the assertion draft and use an example with a Basic > authentic

[OAUTH-WG] New Assertion Drafts Published

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 h

Re: [OAUTH-WG] OAuth mobile flow

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. http://www.slideshare.net/briandavidcampbell/is-that-a-token-in-your-phone-in-your-pocket-or-are-you-just-glad-to-see-me-oauth

Re: [OAUTH-WG] JWT grant_type and client_id

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 wrote: > So currently

Re: [OAUTH-WG] JWT grant_type and client_id

l imply that the client > id will also have to accompany it... > > Cheers, Sergey > > > Thoughts? > > > > adam > > > > *From:*John Bradley [mailto:ve7...@ve7jtb.com] > > *Sent:* Friday, March 15, 2013 12:10 PM > > *To:* Lewis Adam-CAL022 > > *Cc:*

Re: [OAUTH-WG] JWT grant_type and client_id

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 impl

Re: [OAUTH-WG] Support for SAML assertion reference formats in OAuth SAML Assertion profile

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 wrote: > It is a direct connection and not a browser redirect. I don't think there > is much value in supporting something

Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

ying to fix at the >> moment, as I recall from last week). >> >> So it turns into about a paragraph worth of text. Is that worth it? I'm >> not entirely convinced that it is, but I'm interested to hear what others >> think, particularly those who *aren'

Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

large number of clients will be native and might be able to > customize themselves for a single user during registration , we don't want > to forget the web server clients that are multi user. > > On 2013-03-11, at 10:49 PM, Brian Campbell > wrote: > > FWIW, the closely r

Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

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", "cl

Re: [OAUTH-WG] [jose] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10

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 wrote: > 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

Re: [OAUTH-WG] JWT - scope claim missing

radley wrote: >> >> Yes, defining scope in JWT is the wrong place. JWT needs to stick to >> the security claims needed to process JWT. >> >> I also don't know how far you get requiring a specific authorization >> format for JWT, some AS will wan to u

Re: [OAUTH-WG] JWT - scope claim missing

self to interoperability, where AS implementations can > advertise conformance to the profile and who knows … maybe the RS’s of the > future will be good with this. > > ** ** > > adam**** > > ** ** > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.or

Re: [OAUTH-WG] JWT - scope claim missing

ument could be made the other way. On Thu, Feb 28, 2013 at 12:03 PM, Brian Campbell 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

Re: [OAUTH-WG] JWT - scope claim missing

wan to use a opaque reference, some might want > to use a user claim or role claim, others may use scopes, combining scopes > and claims is also possible. > > Right now it is up to a AS RS pair to agree on how to communicate > authorization. I don't want MAC to be more restrictive than

Re: [OAUTH-WG] JWT - scope claim missing

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 d

Re: [OAUTH-WG] Registration: JWK Urls

+1 On Tue, Feb 26, 2013 at 8:05 AM, Justin Richer wrote: > Right now, the Dynamic Registration draft has four URLs that deal with > registering public keys for the client: > > jwk_uri > jwk_encryption_uri > x509_uri > x509_encryption_uri > > These are for use in things like JWK-based assertions

<    6   7   8   9   10   11   12   13   14   >