Hmmm, I see your point but I think that from a privacy PoV revealing the
username to the RP is not good practice, especially not prior to trust being
established between RP and IdP. If the IdP wants to send the assertion in the
authentication statement that is another matter. But you don't want
On 4/10/12 8:25 PM, Mike Jones wrote:
---
About your issue 2: Investigating the OAuth Errors Registry a bit further (see
http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-11.4.1) while I'd
like to be able to register the OAuth Bearer errors in this registry, what I
believe to be a defe
I'm just looking at the parts copied to the list and in the tracker. I haven't
actually seen much response coming from Russ. I did reach out to him directly
to see if the discuss can be resolve without further action.
EH
> -Original Message-
> From: Peter Saint-Andre [mailto:stpe...@stp
On 5/9/12 6:17 PM, Eran Hammer wrote:
> All Russ was asking for is an explanation. Instead, he was told there
> was no good reason and that it should be changed. That was clearly not
> an honest representation of clear working group consensus from over 10
> months ago which was achieved at great e
+1
On 5/9/12 6:27 PM, John Bradley wrote:
Consistent syntax across bearer, core and MAC.
That wasn't one of the options:)
John B.
On 2012-05-09, at 6:06 PM, Hannes Tschofenig wrote:
Hi all,
another issue that came up in Sean's IESG review was about the encoding of the
error / error_descrip
I don't need to repeat three months of extensive arguments. AIRI, you were as
strongly opinionated about this as I was, and it was largely an argument
between my, you, and Tony Nadalin. After we failed to reach WG consensus - we
did resolve some items as you indicated below - the chairs formed a
Hi Mike,
On 05/09/2012 06:41 PM, Mike Jones wrote:
> Looks pretty good to me. I might consider adding a sentence in the paragraph
> that motivates the new work items (that starts with "The ongoing
> standardization effort") to motivate the JWT work items. For instance
> "Having a standard JS
I believe that you're intentionally oversimplifying things. My memory was that
originally you objected to having the OAuth Errors Registry at all. Issue 11
was about getting it created in the first place, despite your objections. The
compromise with you to get you to agree to it was that you
Most people on this WG are not aware of all the details around the on-going
IESG review and my objections to making additional changes to the core
specification. Currently, these are the open issues preventing the bearer
specification from being approved:
>From Russ Housley:
Section 3.1 spec
I am only talking about the error code registry (location and value
restrictions).
Go back to your responses to the IESG questions about adding the errors to the
core spec's registry and you'll clearly see how you failed to represent the WG
consensus. Instead, you should have pointed to the WG
Per the earlier correction to my typo, the DISCUSS was on the bearer spec. It
asked me to reference syntax restrictions for scope and error values the core
spec, that it turns out were not uniformly present there. The chairs decided
to ask the working group whether to add them there (allowing
There was no such discuss on the core specification.
The only open discuss on the core specification related to character sets is to
translate the EXISTING prose into ABNF which will not have any implementation
impact.
The proper response to the bearer specification discuss was to simply add a
+1 for the consistency.
Nat Sakimura
On 2012/05/10, at 0:18, William Mills wrote:
+1
--
*From:* Mike Jones
*To:* Hannes Tschofenig ; "oauth@ietf.org WG" <
oauth@ietf.org>
*Sent:* Wednesday, May 9, 2012 3:15 PM
*Subject:* Re: [OAUTH-WG] Encoding of Errors in the B
Typo. The first sentence below should have started "There was a DISCUSS on the
*bearer* spec"...
-Original Message-
From: Mike Jones
Sent: Wednesday, May 09, 2012 3:41 PM
To: 'Eran Hammer'; Hannes Tschofenig; oauth@ietf.org WG
Subject: RE: [OAUTH-WG] Encoding of Errors in the Base and i
There was a DISCUSS on the core spec asking us to cite the character set
restrictions for scope and error values in the core spec, rather than defining
them in the bearer spec. It turns out that I could not do that as the core
spec is currently written, because the character set restrictions ar
I am confused by the process here.
The IESG review raised a LONG list of discuss items for the core specification.
I was able to successfully address all but three remaining issues:
1. Lack of ABNF - I will do it myself this week since no one else bothered to
offer their help.
2. Registry rules
Consistent syntax across bearer, core and MAC.
That wasn't one of the options:)
John B.
On 2012-05-09, at 6:06 PM, Hannes Tschofenig wrote:
> Hi all,
>
> another issue that came up in Sean's IESG review was about the encoding of
> the error / error_description / error_uri in the base and in t
+1
>
> From: Mike Jones
>To: Hannes Tschofenig ; "oauth@ietf.org WG"
>
>Sent: Wednesday, May 9, 2012 3:15 PM
>Subject: Re: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer Spec
>
>2) Consistent syntax across both OAuth specs.
>
> --
2) Consistent syntax across both OAuth specs.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Hannes Tschofenig
Sent: Wednesday, May 09, 2012 3:07 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Encoding of
Hi all,
another issue that came up in Sean's IESG review was about the encoding of the
error / error_description / error_uri in the base and in the bearer
specification.
As mentioned in my earlier mail about the registry for the error codes there
are three error fields defined in the two spe
Is it correct to say that the IPR in question touched the portion of Bearer
that deals with allowing the token in the URL, and that tokens in the Auth
header and tokens in POST body?
If so, then for me this issue is another reason not to use tokens in the URL,
which I would already recommend a
So, here are statements that you could make as part of this discussion
that would be entirely in scope:
1) I've read the IPR. Prior to this disclosure I was interested in
developing|deploying|shipping an implementation of this
specification. Now I am not.
2) I think you could go so far as to sa
We've moved our git repository away from one that was tied to my
personal account (jricher) and into a more appropriate "GitHub
Organization" one. This means that the URLs pointing to the diagrams
mentioned below have changed. The correct URL is now:
https://raw.github.com/mitreid-connect/Open
On 05/09/2012 09:31 PM, Michael Thomas wrote:
>>
>
> That's not what I read Eran as asking for:
>
> "So no discussion of this is expected on the list - correct?"
Eran is right about the kinds of discussion I mentioned
as not being for the WG.
This is all business as usual, the rules are in RF
On 05/09/2012 01:26 PM, Stephen Farrell wrote:
Hi Mike,
On 05/09/2012 08:34 PM, Michael Thomas wrote:
On 05/09/2012 12:17 PM, Eran Hammer wrote:
Whoever you talk to for legal advice about IPR issues related to
standards you might implement. My only point is, this group is not
qualified to comm
Hi Mike,
you have to by yourself decide whether this IPR (or any other issue) is
important for you.
I cannot do that for you nor can the working group.
Ciao
Hannes
On May 9, 2012, at 10:34 PM, Michael Thomas wrote:
> On 05/09/2012 12:17 PM, Eran Hammer wrote:
>> Whoever you talk to for leg
Simple. By having WG members simply state whether they will or will not adopt
the proposed standard given the IPR issues. Trying to discuss the merits of the
IPR disclosure is impossible.
EH
> -Original Message-
> From: Michael Thomas [mailto:m...@mtcc.com]
> Sent: Wednesday, May 09, 20
Hi Mike,
On 05/09/2012 08:34 PM, Michael Thomas wrote:
> On 05/09/2012 12:17 PM, Eran Hammer wrote:
>> Whoever you talk to for legal advice about IPR issues related to
>> standards you might implement. My only point is, this group is not
>> qualified to comment on IPR matters.
>
> The IETF gets
On 05/09/2012 12:17 PM, Eran Hammer wrote:
Whoever you talk to for legal advice about IPR issues related to standards you
might implement. My only point is, this group is not qualified to comment on
IPR matters.
The IETF gets to decide whether it wants to create standards that
use (potentiall
The lookup is based on the identifier provided by the user. It can have a user
portion in the format of a URI https://j...@example.com ,
https://example.com/john or anything else where you can extract the domain.
The user portion is necessary to allow for per user IdP delegation. Otherwise
o
Thanks. This is the clarification I was seeking.
EH
> -Original Message-
> From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
> Sent: Wednesday, May 09, 2012 12:17 PM
> To: Eran Hammer
> Cc: Hannes Tschofenig; oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] IPR on OAuth bearer
>
> No
Whoever you talk to for legal advice about IPR issues related to standards you
might implement. My only point is, this group is not qualified to comment on
IPR matters.
EH
> -Original Message-
> From: Michael Thomas [mailto:m...@mtcc.com]
> Sent: Wednesday, May 09, 2012 12:15 PM
> To: E
No, don't share your interpretation about the IPR with us on the mailing list.
However, if you come to the conclusion that the IPR situation is unacceptable
for you then you could withdraw your previously stated support for the
document. If everyone or many do that then we have to find a plan B
On 05/09/2012 12:06 PM, Eran Hammer wrote:
So no discussion of this is expected on the list - correct? That's what I wanted to clarify. You
asked the WG to "think" about its potential implications but I don't want that
"thinking" to happen out-loud on this list...
Raising the issue with your i
So no discussion of this is expected on the list - correct? That's what I
wanted to clarify. You asked the WG to "think" about its potential implications
but I don't want that "thinking" to happen out-loud on this list...
Raising the issue with your internal IPR team is the right step.
EH
> --
For SASL-SAML I do something similar, I use the term 'domain', but again this
used to lookup the associated SAML IdP
Klaas
Sent from my iPhone
On 9 mei 2012, at 20:21, "John Bradley" wrote:
> For openID Connect we are using the identifier to discover the AS. We refer
> to that as an issuer
Hi John,
does the "identifier" contain of a domain part AND a username part or only the
domain part?
That's the crucial question here.
Ciao
Hannes
On May 9, 2012, at 9:20 PM, John Bradley wrote:
> For openID Connect we are using the identifier to discover the AS. We refer
> to that as an
This is going to get fun as we deal with various types of identities. There
was a suggestion at IIW that the workable way to do this for e-mail is via MX
records. What do we do for other types of IDs?
>
> From: Hannes Tschofenig
>To: "oauth@ietf.org WG" ; ki
Hi Eran,
if you care about the specification (and want to use it in your products) then
you may want to reach out to your IPR folks and ask for their judgement.
They may be able to tell you whether they find the cited IPR applicable and
whether they had experience with the IPR holder already.
For openID Connect we are using the identifier to discover the AS. We refer
to that as an issuer, and perform a second discovery step to get the
configuration (Auth endpoint, token endpoint, user_info endpoint and other
config) for that issuer.
SWD/WF may be used for other things by other pr
What exactly is the expected WG discussion on this? I hope people here are not
expected to read the patent and make legal decisions about the patent's
validity or even applicability as these are questions for lawyers, not
engineers.
EH
> -Original Message-
> From: oauth-boun...@ietf.or
Hi guys,
at the last IIW we had a discussion about SASL-OAuth and what the SASL server
needs to know for discovery.
The discovery discussions around WebFinger go in the same directions.
So, I have been wondering whether we have made an informed decision about how
the discovery procedure is a
Hi all,
an IPR disclosure had been submitted for the OAuth bearer document recently. In
case you may have missed it, here is the link to it:
https://datatracker.ietf.org/ipr/1752/
The ADs will re-run the IETF last call due to this new IPR filing and we would
also like the working group to che
Looks pretty good to me. I might consider adding a sentence in the paragraph
that motivates the new work items (that starts with "The ongoing
standardization effort") to motivate the JWT work items. For instance "Having
a standard JSON-based assertion format and a profile for using it with OAu
Hi,
There's been a bit of IESG comment on the proposed new
charter resulting in a few editorial changes. So just
in case, the text below is what I'd like to propose for
approval on Thursday.
Let me know if there's anything substantively wrong
here, in which case, we'll probably want to re-spin
t
45 matches
Mail list logo
