W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2002

RE: D-AR006.12 [Was RE: D-AR006.11 discussion points]

From: Joseph Hui <Joseph.Hui@exodus.net>
Date: Thu, 9 May 2002 10:11:05 -0700
Message-ID: <45258A4365C6B24A9832BFE224837D5523BB54@SJDCEX01.int.exodus.net>
To: <www-ws-arch@w3.org>
Hi all,

I've just read my own message sent last and realized
that the following text:

> (There're corner cases one can use
> to make arguments over this characterization.  I'll
> leave them as homework for those who may want to argue.)
 
could be misconstrued as a discouragement for our
continuing "lively" debate over the issues.
I didn't and don't mean to imply any of us have
been argumentative.  Please chime in any time.

Regards,

Joe Hui
Exodus, a Cable & Wireless service
===========================================



> -----Original Message-----
> From: Joseph Hui 
> Sent: Thursday, May 09, 2002 9:47 AM
> To: 'Dilber, Ayse, ALASO'; Christopher Ferris; www-ws-arch@w3.org
> Subject: D-AR006.12 [Was RE: D-AR006.11 discussion points]
> 
> 
> > From: Dilber, Ayse, ALASO [mailto:adilber@att.com]
> > Sent: Thursday, May 09, 2002 7:32 AM
> > To: Joseph Hui; Christopher Ferris; www-ws-arch@w3.org
> > Subject: RE: D-AR006.11 discussion points
> > 
> > Sorry about my e-mail problems, I think the majority of it 
> > has been resolved.  
> > 
> > Here is another proposal:
> > 
> > FROM: There are six aspects in the security framework for 
> Web Services
> > architecture:
> >             Accessibility, Authentication, Authorization, 
> > Confidentiality,
> > Integrity, and Non-repudiation.
> >             Together they form the foundation for secure 
> Web Services.
> > 
> > TO: There are three security primitives in the security 
> > framework for Web
> > Services architecture: Confidentiality, Availability, and 
> > Integrity. 
> 
> This is the first time I've heard "Confidentiality,
> Availability, Integrity" be referred to as security primitives.
> I've already explained the conventional meaning of
> security primitives in couple other messages, so
> won't repeat here.  I participate/tune in many security
> forums, but not all. So I could have missed it somewhere,
> though I doubt it.  Perhaps you could show me where.
> 
> My advise to the WG is that we should stick to nomenclatures
> that are more conventionally known or used in *credible*
> security publications/discourses, and refrain from re-inventing
> new meanings for established terminologies unnecessarily.
> It follows that we stay with the "aspects/facets" terms
> when referring to Accessibility, Authc, Authz, Conf,
> Integrity, and Non-rep.
> 
> Also, Availability is not the same as Accessibility in
> the strictest sense.  E.g. you can have a website
> available all day (by having triple backup sites
> irrespective of security), yet a consumer can't
> access it because its (the consumer's) DNS server
> has been spoofed.  The former pertains to the WS
> provider only, the latter concerns both the provider
> and consumer.  (There're corner cases one can use
> to make arguments over this characterization.  I'll
> leave them as homework for those who may want to argue.)
> 
> > And,
> > together with Authentication (includes identification and 
> > authorization),
> > Access Control (file permission, etc.), Non-repudiation, and 
> > Auditing make
> > up the seven the security principles that form the foundation 
> > for secure Web
> > Services.
> 
> Again, nomenclature issue: the term "principle(s)" connotes 
> "how to do something better."  We want to convey "what 
> constitutes the foundation" in the sentence, because the
> paragraph is meant to be a lite intro for the few reqs to
> follow.  Additionally, as I said in a previous message,
> "Access Control (file permission, etc.)" is an Authz means.
> 
> > ADD to the requirements statements:
> >      - The security framework must include Auditing.
> 
> IMO, this is good -- something I can recommend to the WG
> and the public.  So, unless there're objections, the following
> is going to the WG's floor:
> 
>    D-AR006.12 --
>        The security framework must include Auditing.
> 
> Editors, please take note of the D-AR006.12 addition.
> 
> Thanks,
> 
> Joe Hui
> Exodus, a Cable & Wireless service
> ========================================
> 
> 
> > 
> > -----Original Message-----
> > From: Joseph Hui [mailto:Joseph.Hui@exodus.net]
> > Sent: Wednesday, May 08, 2002 7:50 PM
> > To: Christopher Ferris
> > Cc: Dilber, Ayse, ALASO; www-ws-arch@w3.org
> > Subject: RE: D-AR006.11 discussion points
> > 
> > 
> > > -----Original Message-----
> > > From: Christopher Ferris [mailto:chris.ferris@sun.com]
> > > Sent: Wednesday, May 08, 2002 3:50 PM
> > > To: Joseph Hui
> > > Cc: Dilber, Ayse, ALASO; www-ws-arch@w3.org
> > > Subject: Re: D-AR006.11 discussion points
> > > 
> > > 
> > > Joe,
> > > 
> > > What is a "security primitive" per se? My understanding of
> > > security is based on the premise of risks and balanced
> > > countermeasures based on the level of risk assessed
> > > for each resource. I have never heard of a "security
> > > primitive" before so I have no idea how to respond
> > > to your question.
> > 
> > Off the top of my head, the established security primitives
> > include: encryption (for Confidentiality); message digest (for
> > data Integrity; Public Key Encryption (PKE, for key
> > establishment, which may be further broken down to
> > key exchange and key agreement); digital signature
> > (for non-repudiation), ...  I think you get gist by now.
> > 
> > (Just like doing computer graphics, you have point,
> > draw, fill, ... as graphic primitives.)
> > 
> > > IMO, auditing as a service *might* be something we
> > > consider as an important aspect of web services
> > > security. 
> > 
> > I agree it can be important, but not to the point of
> > being the equal of the original six.
> > 
> > > Or, we might conclude that in terms of priority
> > > that other countermeasure technologies should be considered
> > > ahead of auditing. But that's beside the point.
> > > 
> > > The six "facets" you cite are in fact (IMHO) merely six
> > > countermeasures which comprise but a subset of the
> > > total arsenal of countermeasures that might be applied
> > > to mitigate a risk. Auditing is another, equally valid,
> > > countermeasure that is (or should be!) often employed
> > > within the fabric of a secure environment. There are
> > > other non-technical (and IMHO, far more important)
> > > countermeasures (management comes to mind, without which
> > > all the glitzy technicological countermeasures one
> > > can imagine can be rendered useless overhead) that could
> > > also be included in the list.
> > 
> > Are we going to roll admin/operational elements into the mix now?
> > I thought there was already enough grief given to D-AR006.7
> > through 6.8.  They are admin/operational-ish.
> > 
> > > Why is it that you are so adamantly opposed to its (Auditing)
> > > inclusion in this list? 
> > 
> > Let's not jump to conclusions.  I haven't made up my mind yet
> > whether to oppose it, let alone adamantly. 
> > For Pete's sake, what's the final wording of the req? 
> > 
> > I have already expressed my reservation about grouping Auditing
> > in as a sec aspect.  (Ayse was having mail problem and I'm
> > still waiting on the response that she said she'd sent me.)
> > And I've already responded (favorbly, mind you :-) to the
> > one proposed by Steven A. Monetti.
> > 
> > > A number of others have chimed in suggesting
> > > that its inclusion would be "a good thing(tm)".
> > 
> > No argument ever from me against Auditing being a good thing.
> > 
> > > Would you be willing to live with its inclusion?
> > 
> > Inclusion as a separate req; or inclusion as replacement to
> > supplant the original six?  Like implied earlier, I can
> > live with the simple wording proposed by Steven.
> > Will that be the final wording?
> > 
> > Cheers
> > 
> > Joe Hui
> > Exodus, a Cable & Wireless service
> > =========================================
> > > 
> > > Cheers,
> > > 
> > > Chris
> > > 
> > > 
> > > 
> > > Joseph Hui wrote:
> > > 
> > > >>From: Christopher Ferris [mailto:chris.ferris@sun.com]
> > > >>Sent: Wednesday, May 08, 2002 2:25 PM
> > > >>To: Joseph Hui
> > > >>Cc: Dilber, Ayse, ALASO; www-ws-arch@w3.org
> > > >>Subject: Re: D-AR006.11 discussion points
> > > >>
> > > >>
> > > >>Joe,
> > > >>
> > > >>As with AuthN and AuthZ, it is a countermeasure used
> > > >>to mitigate a security threat(s) such as when AuthN and
> > > >>AuthZ have been (somehow) circumvented. It is also
> > > >>useful to protect against abuse of privileges that
> > > >>may have been granted.
> > > >>
> > > > 
> > > > Chris,
> > > > 
> > > > I'm well aware of the benefits of auditing -- nuts and
> > > > bolts and trimmings; and what auditing may mean in various
> > > > contexts.  (Exodus is a well established vendor of Security
> > > > Audit services, albeit Ayse's notion of Auditing is more
> > > > like logging and our products cover far more than that.)  
> > > > 
> > > > However, I wouldn't elevate it to a "security aspect/facet"
> > > > equal to the original six commonly known to security experts.
> > > > The experts no doubt know what Auditing can mean in the
> > > > context of security, but wouldn't group it in the company
> > > > of the original six for sure.
> > > > 
> > > > Can you think of a security primitive that does Auditing?
> > > > 
> > > > Cheers,
> > > > 
> > > > Joe Hui
> > > > Exodus, a Cable & Wireless service
> > > > =================================================
> > > > 
> > > > 
> > > > 
> > > > 
> > > >>Cheers,
> > > >>
> > > >>Chris-sans-chapeau
> > > >>
> > > >>Joseph Hui wrote:
> > > >>
> > > >>
> > > >>>>-----Original Message-----
> > > >>>>From: Dilber, Ayse, ALASO [mailto:adilber@att.com]
> > > >>>>Sent: Wednesday, May 08, 2002 2:02 PM
> > > >>>>To: Joseph Hui; Christopher Ferris; www-ws-arch@w3.org
> > > >>>>Subject: RE: D-AR006.11 discussion points
> > > >>>>
> > > >>>>
> > > >>>>i don't know if you will receive this but i'm having lots of 
> > > >>>>e-mail problems today, i thought i answered your question in 
> > > >>>>a different message but it sounds like it wasn't delivered.  
> > > >>>>so here it is:
> > > >>>>
> > > >>>>
> > > >>>Well, here it is what?  Another mail problem? ;-)
> > > >>>Please take your time, Ayse.
> > > >>>Fix you mail first; the world can wait. :-)
> > > >>>
> > > >>>Joe Hui
> > > >>>Exodus, a Cable & Wireless service
> > > >>>=============================================
> > > >>>
> > > >>>
> > > >>>>-----Original Message-----
> > > >>>>From: Joseph Hui [mailto:Joseph.Hui@exodus.net]
> > > >>>>Sent: Wednesday, May 08, 2002 4:41 PM
> > > >>>>To: Dilber, Ayse, ALASO; Christopher Ferris; 
> www-ws-arch@w3.org
> > > >>>>Subject: RE: D-AR006.11 discussion points
> > > >>>>
> > > >>>>
> > > >>>>Ayse,
> > > >>>>
> > > >>>>Then what's your answer to my questions in [1]
> > > >>>>pertaining to threat characterization?
> > > >>>>
> > > >>>>I'm copying the text of the original question over
> > > >>>>as follows:
> > > >>>>
> > > >>>> Auditing* as a security aspect?
> > > >>>> Can you explain why?  E.g. for starter, how would you
> > > >>>> characterize the threat (model) that's unique to Auditing?
> > > >>>> Note that the impetus for requiring each of the original
> > > >>>> six begins with a unique threat, or in some cases, threats.
> > > >>>>
> > > >>>>Joe Hui
> > > >>>>Exodus, a Cable & Wireless service
> > > >>>>
> > > >>>>PS: I wasn't interested in what auditing means in
> > > >>>>   the conventional sense.  It's obvious.
> > > >>>>
> > > >>>>[1] 
> > > >>>>
> > > 
> >>http://lists.w3.org/Archives/Member/w3c-ws-arch/2002May/0056.html
> > > >>
> > > >>>>============================================================
> > > >>>>
> > > >>==========
> > > >>
> > > >>>>>-----Original Message-----
> > > >>>>>From: Dilber, Ayse, ALASO [mailto:adilber@att.com]
> > > >>>>>Sent: Wednesday, May 08, 2002 12:59 PM
> > > >>>>>To: Joseph Hui; Christopher Ferris; www-ws-arch@w3.org
> > > >>>>>Subject: RE: D-AR006.11 discussion points
> > > >>>>>
> > > >>>>>
> > > >>>>>No, I didn't back out on Auditing!  I was having serious 
> > > >>>>>e-mail problems that's why I couldn't respond.  I believe 
> > > >>>>>that the Auditing should be included!
> > > >>>>>Ayse
> > > >>>>>
> > > >>>>>-----Original Message-----
> > > >>>>>From: Joseph Hui [mailto:Joseph.Hui@exodus.net]
> > > >>>>>Sent: Wednesday, May 08, 2002 3:55 PM
> > > >>>>>To: Christopher Ferris; www-ws-arch@w3.org
> > > >>>>>Subject: RE: D-AR006.11 discussion points
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>-----Original Message-----
> > > >>>>>>From: Christopher Ferris [mailto:chris.ferris@sun.com]
> > > >>>>>>Sent: Wednesday, May 08, 2002 12:00 PM
> > > >>>>>>To: www-ws-arch@w3.org
> > > >>>>>>Subject: Re: D-AR006.11 discussion points
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>Joe/Ayse,
> > > >>>>>>
> > > >>>>>>1) Please keep this, and all technical discussion, on 
> > the public
> > > >>>>>>mailing list.
> > > >>>>>>
> > > >>>>>>2) It seems to me that Joe is suggesting that the bulleted
> > > >>>>>>item under D-AR006.11 that says:
> > > >>>>>>
> > > >>>>>>"There are six aspects in the security framework for Web 
> > > >>>>>>Services architecture: Accessibility, 
> > > >>>>>>Authentication, Authorization, Confidentiality, Integrity, 
> > > >>>>>>and Non-repudiation. Together they form 
> > > >>>>>>the foundation for secure Web Services.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>The above text is NOT a requirement at all!!!
> > > >>>>>It doesn't even read like one.
> > > >>>>>It's a lite intro for D-AR006.1 thru D-AR006.6.
> > > >>>>>The editors inserted D-AR006.10 and D-AR006.11 in
> > > >>>>>the wrong place.  The two should have followed D-AR009;
> > > >>>>>and the intro should not have been bulletized.
> > > >>>>>What a mess.  sigh.
> > > >>>>>
> > > >>>>>D-AR006.11 text should read as follows:
> > > >>>>>
> > > >>>>> D-AR006.11 The architecture must provide an interface for
> > > >>>>> Web Services to directly communicate with their underlying
> > > >>>>> infrastructure.
> > > >>>>>
> > > >>>>> The interface is for negotiating services that an 
> > infrastructure
> > > >>>>> may provide to, or perform on behalf of, requesting Web 
> > > Services.
> > > >>>>> Such value-added services may include: security, content 
> > > >>>>>
> > > >>delivery,
> > > >>
> > > >>>>> QoS, etc. For instance, a Web service may instruct (via the 
> > > >>>>>interface)
> > > >>>>> the security agents of its infrastructure to defend against
> > > >>>>> DOS/DDOS attacks on its behalf."
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>is actually a separate requirement from D-AR006.11 
> and should 
> > > >>>>>>have been
> > > >>>>>>labeled D-AR006.12 in the document. Am I reading this 
> > > >>>>>>correctly? If so,
> > > >>>>>>then this needs to be fed to the editors as a comment so 
> > > >>>>>>
> > > >>>>>>
> > > >>>>that it is
> > > >>>>
> > > >>>>
> > > >>>>>>certain to be tracked (and fixed in the next 
> editor's draft).
> > > >>>>>>
> > > >>>>>>The question I have then is whether or not Joe is accepting
> > > >>>>>>Ayse's request to add Auditing to this list of 6 aspects
> > > >>>>>>or whether he is suggesting that yet another requirement
> > > >>>>>>(D-AR006.13) be created to accomodate Auditing... do 
> > any others
> > > >>>>>>have an opinion on this?
> > > >>>>>>
> > > >>>>>>
> > > >>>>>I think Ayse has already backed out on Auditing.
> > > >>>>>So it's no longer an issue whether I'd accept it.
> > > >>>>>(I wasn't inclined to accept it because there's no
> > > >>>>>threat model that's uniquely associated with Auditing.
> > > >>>>>But I wouldn't decide one way or the other without
> > > >>>>>hearing the case out first.)
> > > >>>>>
> > > >>>>>Whoever wants to give it another shot is welcome to
> > > >>>>>present his/her *reasoning and analysis*.
> > > >>>>>
> > > >>>>>Cheers,
> > > >>>>>
> > > >>>>>Joe Hui
> > > >>>>>Exodus, a Cable & Wireless service
> > > >>>>>==================================================
> > > >>>>>
> > > >>>>>
> > > >>>>>>Thanks,
> > > >>>>>>
> > > >>>>>>Chris
> > > >>>>>>
> > > >>>>>>Joseph Hui wrote:
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>>>From: Dilber, Ayse, ALASO [mailto:adilber@att.com]
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>[snip]
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>>D-AR006.11 the six aspects need to be replaced with the 
> > > >>>>>>>>following seven aspects of the security framework: 
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>Ayse, the D-AR006.11 number was taken.
> > > >>>>>>>You may want to re-number your proposal as 
> D-AR006.12 instead
> > > >>>>>>>if you're serious about it (to be voted on or debated).
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>>Auditing; 
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>Auditing* as a security aspect?
> > > >>>>>>>Can you explain why?  E.g. for starter, how would you
> > > >>>>>>>characterize the threat (model) that's unique to Auditing?
> > > >>>>>>>Note that the impetus for requiring each of the original
> > > >>>>>>>six begins with a unique threat, or in some cases, threats.
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>>Authentication (includes identification and 
> authorization);
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>Authc & Authz are separate sec aspects. 
> > > >>>>>>>
> > > >>>>>>>Example 1: The security policy of the very system 
> that you're
> > > >>>>>>>using probably includes only Authz but not Authc.  
> To login,
> > > >>>>>>>you simply enter user name and password, the system checks
> > > >>>>>>>the password file and lets you in.  You are not asked to
> > > >>>>>>>authenticate yourself as Ayse.  BTW, password file is known
> > > >>>>>>>to be one form of Access Control List (ACL).
> > > >>>>>>>
> > > >>>>>>>Example 2: Alice's security policy includes Authc & Authz.
> > > >>>>>>>To join Alice's party, Bob must present a certificate to
> > > >>>>>>>Alice to authenticate himself as Bob -- Authc, AND, after
> > > >>>>>>>successful authc (sometimes aka positive identification),
> > > >>>>>>>Alice checks whether Bob is on her guest list (i.e. ACL)
> > > >>>>>>>before allowing him into her party.  
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>>Access Control (file permission, etc.);
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>Access Control is just a Authz means.  (See 
> example 2 above.)
> > > >>>>>>>
> > > >>>>>>>Cheers,
> > > >>>>>>>
> > > >>>>>>>Joe Hui
> > > >>>>>>>Exodus, a Cable & Wireless service
> > > >>>>>>>========================================================
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>>Confidentiality; 
> > > >>>>>>>>Availability; Integrity; Non-repudiation.
> > > >>>>>>>>Thanks,
> > > >>>>>>>>Ayse
> > > >>>>>>>>
> > > >>>>>>>>-----Original Message-----
> > > >>>>>>>>From: Christopher Ferris [mailto:chris.ferris@sun.com]
> > > >>>>>>>>Sent: Saturday, May 04, 2002 10:00 AM
> > > >>>>>>>>To: wsawg public
> > > >>>>>>>>Subject: D-AR006.11 discussion points
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>SUNW: This requirement goes "inside" a web service 
> > and places 
> > > >>>>>>>>requirements
> > > >>>>>>>>on how it is designed.  We should be focusing on 
> externally 
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>observable
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>>>(through the web service interfaces) behaviour
> > > >>>>>>>>
> > > >>>>>>>>SYBS: Implementation details. Don't seem to fit in Web 
> > > >>>>>>>>Services Architecture
> > > >>>>>>>>group..
> > > >>>>>>>>
> > > >>>>>>>>W3C: See 
> > > >>>>>>>>
> > > >>>>>>>>
> > > 
> > 
> >>>>>http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0015.html
> > > >>>>>
> > > >>>>>
> > > >>>>>>>ORCL: I don't quite see how "an architecture" can actually 
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>provide an
> > > >>>>>
> > > >>>>>
> > > >>>>>>>interface. And in this case the goal may be too ambitious 
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>given the
> > > >>>>
> > > >>>>
> > > >>>>>>>number of different possible "infrastructures".
> > > >>>>>>>
> > > >>>>>>>PF: I just don't see the need for this.
> > > >>>>>>>
> > > >>>>>>>TIB: not clear to me that individual Web services would 
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>ever want to
> > > >>>>
> > > >>>>
> > > >>>>>>>know whether they were under DOS at some lower layer
> > > >>>>>>>
> > > >>>>>>>CrossWeave: Don't understand this
> > > >>>>>>>
> > > >>>>>>>CMPQ: The interface is for negotiating services that an 
> > > >>>>>>>infrastructure may
> > > >>>>>>>provide to, or perform on behalf of, a requesting 
> > Web Services.
> > > >>>>>>>Such value-added services may include: security, content 
> > > >>>>>>>
> > > >>delivery,
> > > >>
> > > >>>>>>>QoS, etc. For instance, a Web service may instruct 
> (via the 
> > > >>>>>>>interface) the security
> > > >>>>>>>agents of its infrastructure to defend against DOS/DDOS 
> > > >>>>>>>attacks on its behalf.
> > > >>>>>>>
> > > >>>>>>>This seems to say that the requirement is
> > > >>>>>>>"The security framework must provide for negotiations 
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>pertaining to
> > > >>>>
> > > >>>>
> > > >>>>>>>security considerations."
> > > >>>>>>>
> > > >>>>>>>That is, the requirement is for negotiation 
> support;  within 
> > > >>>>>>>security context,
> > > >>>>>>>it is security negotiation, within QoS context, it is QoS 
> > > >>>>>>>negotiation, etc.
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>
> > > >>
> > > >>
> > > > 
> > > 
> > > 
> > > 
> > 
> 
Received on Thursday, 9 May 2002 13:11:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:24:59 GMT