ith more experience
> reading over it.
RFC 6365 is your friend. :-)
And no, I have not read the entire thread on the topic here, but if
pressed into service I will review the proposed text. This i18n stuff
can be tricky. ;-)
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-BEGIN PGP SIGNATU
ly as
the ASCII range of characters within the Unicode coded character set
since the characters in the ASCII range are represented using the same
bytes under UTF-8 as they were back in the old days of the ASCII
character encoding scheme.
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-BEG
T be
encoded using something like UTF-8 (which we prefer in IETF protocols)
or UTF-16 or whatever. So it is incorrect to say that "UTF-8 is just
plain wrong, as once you’re in JSON you’re just dealing with Unicode
strings". It doesn't work that way!
Peter
- --
Peter Saint-Andre
htt
Putting the parameters in alphabetical order would make the page more
readable, but other than that it seems fine.
On 8/7/12 6:52 PM, Dick Hardt wrote:
> Would appreciate a few others checking to make sure the IANA entries are
> valid.
>
> -- Dick
>
> Begin forwarded message:
>
>> *From: *"Ama
Indeed. Many thanks to Eran!
On 7/23/12 11:08 AM, Brian Campbell wrote:
> +1
>
> Well said Justin. And thank you Eran.
>
> On Mon, Jul 23, 2012 at 11:05 AM, Richer, Justin P. wrote:
Eran Hammer has decided to step down as Editor of the OAuth Core
specification. I would like to person
On 6/25/12 9:46 PM, Brian Campbell wrote:
> -05 changes the registration procedure for urn:ietf:params:oauth:*
> URNs from Expert Review to Specification Required.
I've reviewed this version and it seems fine.
/psa
___
OAuth mailing list
OAuth@ietf.org
entifier-within-class" component, with the two components being
> separated by a colon (":"); other compositions of the may
> also be used.
WFM.
Peter
--
Peter Saint-Andre
https://stpeter.im/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
ething;-)
>
> (4) Isn't the template missing the reference to the RFC or
> other specification that defines the URN?
>
> (5) I don't get section 3, sorry;-) Can you give an example of
> a class:id pair that'd be registered? Asking IANA to generate
>
On 6/13/12 10:03 AM, Eran Hammer wrote:
> These are straight link relation registrations, not LRDD (which has no
> registration process).
Right you are!
/psa
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
You can remove the reference for draft-hammer-hostmeta (RFC 6415 has
what you need).
Peter
--
Peter Saint-Andre
https://stpeter.im/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I must say that I found it surprising, too. An explanation beforehand
from the chairs would have helped to prevent confusion.
On 6/8/12 3:28 PM, Eran Hammer wrote:
> What the hell just happened? Even if this is allowed under IETF rules,
> it is clearly against IETF spirit. There is now a published
T?)
>
> No, please forget about TEXT. It's gone from HTTP-
>
> If you define new protocol elements, either restrict them to US-ASCII,
> or find a way to encode all of Unicode. Restricting to ISO-8859-1 is a
> non-starter.
+1 to that.
Peter
--
Peter Saint-Andre
https://stpe
ved at great effort.
Was it presented this way in the proto write-up or verbally on an IESG
telechat or in some other way? Just curious to figure out where things
went awry here...
Peter
--
Peter Saint-Andre
https://stpeter.im/
___
OAuth mailin
Barry, I think your text is sufficient.
Hannes, I agree with your point about taking this up outside the OAUTH
WG because this is a broader issue.
Phil, I've reviewed things again and I think Michael is simply in the
rough here, but if Michael thinks that Barry's text is insufficient then
he is f
from http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-04.)
>
>
>
> Do people agree with this URN choice?
Looks fine to me.
Peter
--
Peter Saint-Andre
https://stpeter.im/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Indeed you are right, I'd forgotten about that.
On 4/24/12 12:05 PM, Eran Hammer wrote:
> Barry did make a consensus call when this was originally raised.
>
> EH
>
>> -Original Message-----
>> From: Peter Saint-Andre [mailto:stpe...@stpeter.im]
>> Sent: Tu
sagrees therefore we can move on.
However, I think you know that anyway. :)
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+W2nAACgkQNL8k5A2w/vx
suggested) for
such schemes to make recommendations about the actual data that is
conveyed, without special-casing the parsing rules as such (if the OAuth
WG wishes to go down that path, then further discussion with the HTTPbis
WG would probably be helpful so that
tocols. Given that OAuth as
defined by the core spec runs over HTTP, I think referencing RFC 2818
would make sense. So something like:
The client MUST validate the authorization server's
TLS certificate in accordance with the rules for
server identity authentication provided in Section
reference to Informational RFC 2818 (HTTP over TLS).
>
> * There is a normative reference to Informational RFC 4627
> (application/json Media Type).
The last two are already in the downref registry:
http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
Peter
--
Peter Saint-Andr
o the RFC Editor team for final copy editing, proofreading,
reference checking, etc.
As you can see, because there are still many steps left in the process,
it might be a few months before these specs are published as RFCs.
Just so you know!
Peter
--
Peter Saint-Andre
https://stpeter.im/
or alternative text. Sure, I could wait for the
authors, editors, working group chairs, or area directors to take
action, but you will have much greater success if you actively contribute.
Just my gram of silver...
Peter
--
Peter Saint-Andre
http://stpeter.im/
_
On 12/1/11 1:57 PM, Stephen Farrell wrote:
>
>
> On 12/01/2011 08:10 PM, Peter Saint-Andre wrote:
>> On 12/1/11 1:09 PM, Rob Richards wrote:
>>> On 11/28/11 10:39 PM, Barry Leiba wrote:
>>>>> The OAuth base doc refers in two places to TLS versions (
or me as it's not mandating anything that isn't
> readily available. Only comment is whether or not there is a need to
> even talk about the specific versions or if just the following is enough:
>
> The authorization server MUST implement TLS. Which ver
On 11/29/11 12:49 PM, Brian Hawkins wrote:
> I'm having trouble finding information on how to do 2leg authentication
> with OAuth 2.0. Does it even support it?
This issue comes up often enough that it deserves to be in a FAQ.
Peter
--
Peter Saint-Andre
https:/
On 11/17/11 1:32 PM, William Mills wrote:
> is there a chat room I can poke comments into?
xmpp:oa...@jabber.ietf.org?join
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Finally processed.
On 1/28/11 8:24 AM, Eran Hammer-Lahav wrote:
Verified as correct.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Peter Saint-Andre
Sent: Thursday, November 18, 2010 6:26 PM
To: OAuth WG
Subject: [OAUTH-WG] Fwd
security considerations point to RFC 3553, but that just points to
RFC 2141, so you might as well point to the latter spec.
Peter
--
Peter Saint-Andre
https://stpeter.im/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
the "Bearer" authentication scheme).
Peter
--
Peter Saint-Andre
https://stpeter.im/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
ed
> it. There's FUD here, but not from me.
Mike, did you propose text to address the concern? Per recent discussion
I think the threat-model document is the right place for it, so please
take a look at that spec to see where your proposed text can slot in.
Peter
--
Peter Saint-Andre
https:
ough
usability is not exactly easy in the case of, say, TLS with PKI certs
issued by certification authorities (as witness recent events -- have
you scrubbed your root cert store lately?).
Peter
--
Peter Saint-Andre
https://stpeter.im/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
On 9/6/11 6:50 PM, Melinda Shore wrote:
> On 09/06/2011 04:23 PM, Peter Saint-Andre wrote:
>> I just looked at the most recent specifications for TLS (RFC 5246) and
>> secure shell (RFC 4253), which I think we'd all agree are two quite
>> successful security technologi
On 9/6/11 6:33 PM, Michael Thomas wrote:
> On 09/06/2011 05:23 PM, Peter Saint-Andre wrote:
>> On 9/6/11 4:22 PM, Melinda Shore wrote:
>>
>>> On 09/06/2011 12:59 PM, John Kemp wrote:
>>>
>>>> The point is that you have a point.
>>>>
ser might enter. Not
only is OAuth "not a superhero" as John Kemp said, but I fail to see why
we need to document exactly which superhero powers OAuth lacks (given
that it's not reasonable to expect *any* security protocol to have
I tried to help Justin off-list, but it would be nice to have a FAQ
somewhere that shows developers how to translate from OAuth 1.1 to OAuth
2.0, even just conceptually (as in, "they got rid of the legs, how do I
do two-legged auth in OAuth 2.0?!?").
On 8/26/11 5:04 PM, Justin Karneges wrote:
> Hi
;> 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
>>
>>
>> ___
>> 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
--
Peter Saint-Andre
https://stpeter.im/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Maybe the feature was added anonymously. ;-)
On 8/11/11 2:25 PM, Dick Hardt wrote:
> If it was, no one told me.
>
> On 2011-08-11, at 12:41 PM, Anthony Nadalin wrote:
>
>> Anonymity was certainly part of the design for WRAP
___
OAuth mailing list
OAut
publication of an RFC for the bearer token format spec...
Peter
--
Peter Saint-Andre
https://stpeter.im/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
On 7/31/11 8:45 AM, Barry Leiba wrote:
> On Sat, Jul 30, 2011 at 12:47, Peter Saint-Andre wrote:
>> On 7/29/11 3:07 PM, Brian Campbell wrote:
>>> Following up from
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html a few
>>> weeks ago, I&#x
es originally wrote all the content, I've listed him as an
> author. Let me know if that's not appropriate.
I'm happy to sponsor this draft if the Security ADs think it is too
"appsy", but I think it's completely straightforward.
Peter
--
Peter Saint-Andre
https://stpe
On 7/25/11 4:06 AM, Eran Hammer-Lahav wrote:
> Draft 19 includes all the feedback received for -18:
BTW, the diff is here:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-19.txt
/psa
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai
last call on
> that within the month.
Does "within the month" mean "by the end of June"? :)
Peter
--
Peter Saint-Andre
https://stpeter.im/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
On 6/2/11 8:38 PM, Brian Eaton wrote:
> On Thu, Jun 2, 2011 at 7:13 PM, Peter Saint-Andre <mailto:stpe...@stpeter.im>> wrote:
>
> I'm not thinking about your use case, but things like enterprise
> deployments in high-security environments where every perso
On 6/2/11 6:48 PM, Brian Eaton wrote:
> On Thu, Jun 2, 2011 at 5:08 PM, Peter Saint-Andre <mailto:stpe...@stpeter.im>> wrote:
>
> I think the SHOULD we had originally is probably fine -- with the
> understanding that "SHOULD" means "you really ough
On 6/2/11 4:11 PM, Brian Eaton wrote:
> On Thu, Jun 2, 2011 at 3:01 PM, Peter Saint-Andre <mailto:stpe...@stpeter.im>> wrote:
>
> I think I might have misunderstood that text -- I took it to be talking
> about the client's authentication with the aut
clients that have no way of
> authenticating are issued long-lived credentials to access user data.
I think I might have misunderstood that text -- I took it to be talking
about the client's authentication with the authorization server, not the
client's authentication with the resourc
pe-specific attributes). The client
MUST NOT use an access token if it does not understand or does not
trust the token type.
RATIONALE: An application could understand a given token type but not
trust it (or not trust it from the sender).
8.1. Defining Access Tok
ints) are allowed in the client_id parameter, how long
it can be, how to perform comparison for authentication purposes, etc.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
bring that question up?
>
> Also, is there an irc channel to log into for this meeting. I may be
> easier to type in my comments
Probably good to use the Jabber room for this working group:
xmpp:oa...@jabber.ietf.org
I'm in that room but no one else is at the moment.
Peter
--
On 5/10/11 8:34 AM, David Recordon wrote:
> Anyone else noticed that they overlap each other this year? :-/
Yeah, it's a bummer.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_
Eran, that is my recollection as well.
Possibly there could be consensus to add text like this if list
discussion leads in that direction, but as I recall there was no such
consensus when you provisionally added the text in [[...]] to the base spec.
Peter
On 4/16/11 10:58 AM, Eran Hammer-Lahav w
e why we can't just use existing
HTTP authentication schemes. If BASIC and DIGEST aren't good enough,
then someone needs to develop a new HTTP authentication scheme. However
that's not a job for the OAuth WG as far as I can see...
Peter
--
Peter Saint-Andre
https://stpeter.im/
s
+1, Barry is very good.
On 4/13/11 1:55 PM, Zeltsan, Zachary (Zachary) wrote:
> I have been involved with MARF WG, which Barry co-Chairs, and am sure that
> this appointment is a good news for OAUTH.
>
> Zachary
>
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...
.
Let's complete the important work of the OAuth WG and do the best we can
to make HTTP-based authorization more secure.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing
g might not have time to review the
proposal in 48 hours or less. I know I won't have time to double-check
the list threads and document history on this point until next week.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptog
f you just want to listen.
Thanks!
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Well, the IESG won't approve a document that doesn't include a Security
Considerations section. :)
I'll talk with Hannes about this in person here in Prague (he's sitting
next to me at the moment, but we're in a meeting so we can't chat).
On 3/27/11 10:19 AM, Eran Hammer-Lahav wrote:
> I guess yo
example, see a document that Jeff Hodges and I recently worked on:
http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14
HTH,
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
___
tedt-oauth-security-01
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
oun...@ietf.org] On Behalf
>> Of Peter Saint-Andre
>> Sent: Wednesday, March 23, 2011 2:27 PM
>
>> 3. In the definition of "token endpoint" in Section 2, should "used to
>> exchange an authorization grant for an access token" be "used to exch
Done.
On 3/24/11 6:14 PM, Ruhrstadt-Agentur Com4 wrote:
> Hi Craig,
>
> could you pls. remove me from the lists.
> I coudn't find a unsubscribe-buton on the site.
>
> Thx. and regards,
>
> Gabi
>
>
> *Gabi Banfield
> *
> Ruhrstadt-Agentur Com4
>
> Düsseldorfer Str. 35
>
> 44143 Dortmund
>
stry of locations, but it might be good
to have a well-defined way of adding to the list of allowable locations
(otherwise a document like the bearer spec might need to say that it
updates the base spec).
16. In Section 11.1, I think RFC 2616 needs to be a normative reference.
That's it for now!
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
o launch an attack.
9. Regarding identity verification of resource servers, please reference
either RFC 2818 or draft-saintandre-tls-server-id-check.
10. In Section 4.1.1, I would agree with other WG participants that use
of "oauth_token" here is problematic.
11. Why is Section 4.2 on the
think it would be better to reference the definitions in the base spec
so that they don't get out of sync.
3. Regarding "invalid_grant" in Section 2.3, I'll post in the thread
about a possible registry of error parameter values.
Peter
--
Peter
+1.
Discussion on the apps-discuss list would be welcome:
https://www.ietf.org/mailman/listinfo/apps-discuss
On 3/17/11 4:57 PM, Eran Hammer-Lahav wrote:
> This proposal goes far beyond just solving any discovery needs for
> OAuth. It also directly competes with existing (deployed) proposals.
>
On 3/11/11 3:22 PM, Igor Faynberg wrote:
> Peter,
>
> First, thank you very much for being so responsive!
I'm not always so responsive. You got lucky. :)
> My hope was that we could start much earlier than on Thursday, and I've
> been trying to coax Torsten to arrive no later than Monday. He sho
On 3/11/11 12:10 PM, Peter Saint-Andre wrote:
> On 3/11/11 11:44 AM, Igor Faynberg wrote:
>> Peter,
>>
>> Could you please advertise the room when it is reserved?
>
> Certainly.
>
> I'd appreciate it if those who want to join this working session could
>
On 3/11/11 11:44 AM, Igor Faynberg wrote:
> Peter,
>
> Could you please advertise the room when it is reserved?
Certainly.
I'd appreciate it if those who want to join this working session could
speak up on the list so that I can assign a "point person" and so that
we can figure out how big a roo
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Folks, a dedicated list has been established for discussion about
requirements and potential implementation of JSON to provide security
services for Web-based applications. You can subscribe here:
https://www.ietf.org/mailman/listinfo/woes
On 2/3/11 3:52 AM, Hannes Tschofenig wrote:
> Hi all,
>
ecstatic, hopeful, yearning) to take comments, although I
> guess the etiquette is that it should happen on the Kitten WG mailing
> list?
>
> -bill
>
>> -Original Message- From: oauth-boun...@ietf.org
>> [mailto:oauth-boun...@ietf.org] On Behalf Of Peter Saint-And
Just saw this come across the wire...
Original Message
Subject: I-D Action:draft-mills-kitten-sasl-oauth-01.txt
Date: Wed, 16 Feb 2011 14:45:01 -0800
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
A New Internet-Draft is available fro
It seems that this group probably could have a productive meeting in
Prague. This is just a reminder that the deadline for requesting a slot
is next Monday, February 14. :)
http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
With my individual contributor hat on, I too prefer #1 -- it's just a
lot cleaner to my mind.
On 2/3/11 6:41 PM, David Recordon wrote:
> Also #1. While I feel for existing implementations of "OAuth2" by
> itself, it's not the best name for this specific piece of
> functionality and Facebook too ha
Agreed.
I'll poke the chairs about accepting this as a WG item. :)
Peter
On 12/14/10 6:26 PM, Eran Hammer-Lahav wrote:
> Prepare a new draft if needed and submit it with draft-ietf-oauth-
> prefix. One of the chairs will need to approve it and it will be
> published. I think we have wide conse
Thanks to Thomas for updating this document, which I continue to think
is quite interesting and helpful...
Original Message
Subject: I-D Action:draft-hardjono-oauth-kerberos-01.txt
Date: Wed, 08 Dec 2010 13:00:01 -0800
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf
Folks, is this erratum accurate?
Original Message
Subject: [Technical Errata Reported] RFC5849 (2550)
Date: Tue, 12 Oct 2010 09:42:17 -0700 (PDT)
From: RFC Errata System
To: e...@hueniverse.com, i...@iesg.org
CC: alasd...@lovefilm.com, rfc-edi...@rfc-editor.org
The following
I've been in the room since 18:05 and several other folks are here, but
I don't see the WG chairs...
On 11/9/10 12:47 PM, Hannes Tschofenig wrote:
> Hi all,
>
> at yesterday's security session we discussed ways on what to provide
> in the security consideration for the OAuth specifications. The p
On 11/8/10 7:57 AM, Hannes Tschofenig wrote:
> We will meet there in 13:00 (till 15:00).
Which day? :)
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
ity" and it does not
mean "one vocal person can launch their own personal DoS against the
WG". The chairs (and if necessary the sponsoring AD) do have tools at
their disposal for declaring consensus.
That said, I think your proposal is a reasonable compromise for how to
m
Blaine said he will post them, but I'm not sure when.
On 7/30/10 11:18 AM, Yoav Nir wrote:
> Any chance of postings the sources for today's diagrams
> (now that we can render them ourselves)
>
> On Jul 30, 2010, at 10:45 AM, Peter Saint-Andre wrote:
>
>> As refer
As referred to in the tutorial just now:
http://plantuml.sourceforge.net/
Peter
--
Peter Saint-Andre
https://stpeter.im/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I see no recording equipment in the room.
On 7/29/10 1:49 PM, Gregory Lebovitz wrote:
> Hannes,
> Will the session be recorded, i.e. audio archive and notes/minutes
> created? I think this would be VERY useful.
>
> Gregory.
>
> On 7/29/10 4:15 AM, Hannes Tschofenig wrote:
>> The meeting room is
On 7/21/10 11:58 AM, David Recordon wrote:
> What is the rechartering discussion?
Our charter says we're working on OAuth 1.1. Clearly that is not the
case. Aligning the charter with reality might be a good idea. :)
Peter
--
Peter Saint-Andre
https://st
Thomas, thanks for writing this draft. I finally got a chance to read it
this morning and it is quite helpful and relevant. Do you plan to update
it at some point in the light of more recent versions of the core draft?
On 6/9/10 1:17 PM, Thomas Hardjono wrote:
>
> I was prompted to write this dra
old a developer hackfest on Sunday or at some
other time (outside of normal meeting hours so as not to overlap with
scheduled sessions).
The schedule is very full and many working groups were denied extra
sessions, so I hope we'll make good use of the two sessions we've been
granted
t a re-charter needs to be done. I'll work with Hannes
and Blaine on that. We'd probably have proposed charter text for
discussion at the next IETF meeting but would not have time to complete
the recharter by then, because there's simply not enough time to get
that done in the next
>
>> I dont think it is realistic to require anything higher than TLS 1.0.
Typically, specifications do the following:
1. Require support for Transport Layer Security.
2. Point to the latest specification of that technology (RFC 5246).
3. Prohibit or strongly discourage use of some older
On 6/9/10 7:30 AM, Thomas Hardjono wrote:
> Is there a diff version of this draft (eg. a marked PDF say)?
Check the two "diff" links at the top of the page here:
http://tools.ietf.org/html/draft-ietf-oauth-v2-06
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
__
IETF fashion, I welcome those who care about this
issue to write an Internet-Draft. :)
BTW, it's possible that you might glean some interesting ideas from a
previous attempt to define an open token format (for cookies):
http://tools.ietf.org/html/draft-smith-opentoken-02
Peter
--
Pete
s definitely true. At the interim
meeting we had some discussion about perhaps pulling the assertion flow
out of the base spec and into a separate document. Perhaps that's the
best way to proceed.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME C
Do you mean minutes?
The chairs are working on that, AFAIK.
/psa
On 6/1/10 1:20 PM, Torsten Lodderstedt wrote:
> is there a protocol of the interim meeting?
>
> Am 01.06.2010 20:47, schrieb Peter Saint-Andre:
>> We discussed this a bit at the interim meeting, but I don't
We discussed this a bit at the interim meeting, but I don't think we
came to any consensus.
On 6/1/10 12:46 PM, Torsten Lodderstedt wrote:
> Is there anyone who can answer my questions?
>
> Am 30.05.2010 17:56, schrieb Torsten Lodderstedt:
>> I have some questions regarding the WWW-Authenticate h
Please reply just to me
>> to reduce list spam.
>
> Is there a calendar of upcoming meetings somewhere?
This is a (rare) in-person interim meeting. Presumably the next
in-person meeting will be at IETF 78 in Maastricht:
http://www.ietf.org/meeting/78/index.html
Peter
--
Peter Sain
Ask and ye shall receive:
http://tools.ietf.org/id/draft-ietf-oauth-v2-01.html
The tools team rocks.
On 4/29/10 4:09 PM, Joseph Smarr wrote:
> Any way to get a pretty xml2rfc-style HTML output (like we use for OAuth
> 1.0), or is that too fluffy for the hardcore IETF types? :) Thanks, js
>
> On
On 4/29/10 4:09 PM, Joseph Smarr wrote:
> Any way to get a pretty xml2rfc-style HTML output (like we use for OAuth
> 1.0), or is that too fluffy for the hardcore IETF types? :) Thanks, js
Yeah, I don't know why the tools team doesn't do that if it has the XML
source. Time for a request to tools-di
here are also HTML and PDF, go here for links:
http://tools.ietf.org/html/draft-ietf-oauth-v2-00
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https:/
On 4/26/10 3:14 PM, Marius Scurtescu wrote:
> +1
>
> I am assuming this means that the current draft will become the
> initial check point, version 00. Is that correct?
Correct.
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth ma
On 4/23/10 3:30 PM, Blaine Cook wrote:
> On 23 April 2010 17:01, Peter Saint-Andre wrote:
>> On 4/23/10 8:05 AM, Prateek Mishra wrote:
>>> Do you mean April 29 (Thu) and April 30th (Fri)?
>>
>> Clearly yes.
>
> lol, neither. I think I managed to look at a 200
On 4/23/10 8:05 AM, Prateek Mishra wrote:
> Do you mean April 29 (Thu) and April 30th (Fri)?
Clearly yes.
>> This is a call for consensus on accepting Eran's latest OAuth draft,
>> draft-hammer-oauth2 [1] as a working group item. Assuming no
>> objections by end-of-day Tuesday, April 22nd, this d
1 - 100 of 166 matches
Mail list logo
